I'm building a project with
Ubuntu 14.04 Vagrant box
So this was an absolute pain, but I've managed to get it running sweetly.
Speed Up Vagrant
If you're using Vagrant, make sure your synced folders use NFS. eg:
config.vm.synced_folder ".", "/var/www", type: "nfs"
I saw a roughly 400% speed increase in loading Symfony2 pages.
For extra speed, you can also enable opcache. It comes with PHP 5.5 and is available as an extension for earlier versions. This gave me another 200-300% speed increase. (about 1000% in total).
Speed up XDebug
The biggest speed hit came from xdebug's collection of parameters for stack traces. You can disable that by adding
xdebug.collect_params = 0 to your
Code coverage checks also have a performance cost, so if you don't need them, disable them. Set
xdebug.coverage_enable = 0.
Profiling is also slow, so only enable it when you need it. Set
xdebug.profiler_enable = 0 and
xdebug.profiler_enable_trigger = 1 then use a browser plugin to enable it when you need it. I use Easiest XDebug for Firefox.
That should be everything you need. Below is my complete xdebug config (appologies for the less than stellar code highlighting):
; == Xdebug == ; When executing a script, what should xdebug collect information about? ; This seems to be purely for displaying the error stack. ; Collection of parameters can slow xdebug to a crawl. ; Breakpoints in PhpStorm will still have all of this info. xdebug.collect_includes = 0 xdebug.collect_params = 0 xdebug.collect_return = 0 xdebug.collect_vars = 0 ; http://xdebug.org/docs/code_coverage ; If you want to check that your unit tests cover all lines of your code you should enable this. xdebug.coverage_enable = 0 ; A name to identify this instance of xdebug. xdebug.idekey = "PHPSTORM" ; Maximum function nexting allowed. Symfony needs ~70 or 80. Complex twig templates require more. xdebug.max_nesting_level = 100 ; 1 = Use xdebug's implementation of var_dump. ; 2 = Also add file names and line numbers to var dumps. xdebug.overload_var_dump = 2 ; Disable the profiler by default (because it slows things down) but allow it to be set with a cookie. ; Set a cookie: XDEBUG_PROFILE / Use a browser plugin. xdebug.profiler_enable = 0 xdebug.profiler_enable_trigger = 1 xdebug.profiler_output_dir = "/var/www/logs/profiler" xdebug.profiler_output_name = "cachegrind.out.%t-%s" ; Disable XDebug by default but allow it to be enabled with a cookie. ; Set a cookie: XDEBUG_SESSION / Use a browser plugin. xdebug.remote_autostart = 0 xdebug.remote_enable = 1 ; When remote_connect_back=1 xdebug automatically attempts to connect to the computer making the request. ; It means you don't have to worry about setting your ip address / host name in php.ini. Useful for lazy people :-) ; DON'T DO THIS IN PRODUCTION BECAUSE ANYONE WILL BE ABLE TO MAKE XDEBUG CONNECTIONS. ; When remote_connect_back=0, xdebug will attempt to connect to xdebug.remote_host instead (not specified in this example). xdebug.remote_connect_back = 1; ; Allow traces with a cookie. ; Set a cookie: XDEBUG_TRACE / Use a browser plugin. xdebug.trace_enable_trigger = 1; xdebug.trace_output_dir = "/var/www/logs/trace" xdebug.trace_output_name = "trace.%c" ; When doing var dumps, limit the amount of information shown. xdebug.var_display_max_children = 128 xdebug.var_display_max_data = 512 xdebug.var_display_max_depth = 3
Using XDebug with PHP CLI
Using the config above, xdebug won't be enabled by default when running command line scripts. To debug a cli script using PHPStorm, run php like this:
php -dxdebug.remote_autostart=1 -dxdebug.remote_host=10.0.2.2 your_script.php
xdebug.remote_host should be set to the IP address of the machine with PHPStorm installed. This is probably the host machine for the Vagrant box, which usually defaults to