The following video describes how to debug PHP applications using PHP Xdebug extension and PHPStorm.The video describes this on Windows Xampp installation, b. Instruct XDebug to connect to host.docker.internal for command line execution or whenever “connect back” is not possible. Set PHPIDECONFIG env variable to serverName=localhost. This will tell your PhpStorm which server configuration to use. See next step for details.

FeaturesPhpStorm

Hello everybody,

Xdebug is a great tool and many of you use it for interactive debugging. But Xdebug is not just a debugger, it also provides many other features such as profiling or code coverage

Integration with Xdebug Profiler is one of the most voted feature in the PhpStorm issue tracker, so we are happy to announce that its initial support is already implemented in PhpStorm 3.0 EAP!

To be more specific – PhpStorm provides visual representation of profiling data generated by Xdebug. In order to open a profiler snapshot, invoke the ‘Analyze Xdebug profiler snapshot’ action and select the path to the snapshot. Note that you can select several snapshots at a time and collect the aggregated profiling information.

'Analyze Xdebug profiler snapshot' action in 'Tools' menu

By now we have implemented the following data views:

• ‘Execution Statistics’ – displays summary information about execution metrics of every called function.
• ‘Call Tree’ – displays the execution paths of the called functions.

  'Call Tree' view

• ‘Callees’ – same as ‘Call Tree’ but with the selected function as the root.
• ‘Callers’ – all the paths that can result in calling the selected function.

To learn how to configure the Xdebug extension so profiling is enabled follow official documentation at http://xdebug.org/docs/profiler#starting. You can use our Xdebug bookmarklets generator to toggle profiling directly from browser toolbar.

Developing integration with the profiler is still in progress, so we are looking forward for your feedback!

Develop with pleasure!

Profiling PHP with XDebug

(This post is a fork of a draft version of a tutorial / guide originally written as an internal document whilst at my internship.)

Since I've been looking into xdebug's profiling function recently, I've just been tasked with writing up a guide on how to set it up and use it, from start to finish - and I thought I'd share it here.

While I've written about xdebug before in my An easier way to debug PHP post, I didn't end up covering the profiling function - I had difficulty getting it to work properly. I've managed to get it working now - this post documents how I did it. While this is written for a standard Debian server, the instructions can easily be applied to other servers.

For the uninitiated, xdebug is an extension to PHP that aids in the debugging of PHP code. It consists of 2 parts: The php extension on the server, and a client built into your editor. With these 2 parts, you can create breakpoints, step through code and more - though these functions are not the focus of this post.

To start off, you need to install xdebug. SSH into your web server with a sudo-capable account (or just use root, though that's bad practice!), and run the following command:

Windows users will need to download it from here and put it in their PHP extension direction. Users of other linux distributions and windows may need to enable xdebug in their php.ini file manually (windows users will need extension=xdebug.dll; linux systems use extension=xdebug.so instead).

Once done, xdebug should be loaded and working correctly. You can verify this by looking the php information page. To see this page, put the following in a php file and request it in your browser:

If it's been enabled correctly, you should see something like this somewhere on the resulting page:

With xdebug setup, we can now begin configuring it. Xdebug gets configured in php.ini, PHP's main configuration file. Under Virtualmin each user has their own php.ini because PHP is loaded via CGI, and it's usually located at ~/etc/php.ini. To find it on your system, check the php information page as described above - there should be a row with the name 'Loaded Configuration File':

Once you've located your php.ini file, open it in your favourite editor (or type sensible-editor php.ini if you want to edit over SSH), and put something like this at the bottom:

Obviously, you'll want to customise the above. The xdebug.profiler_enable_trigger_value directive defines a secret key we'll use later to turn profiling on. If nothing else, make sure you change this! Profiling slows everything down a lot, and could easily bring your whole server down if this secret key falls into the wrong hands (that said, simply having xdebug loaded in the first place slows things down too, even if you're not using it - so you may want to set up a separate server for development work that has xdebug installed if you haven't already). If you're not sure on what to set it to, here's a bit of bash I used to generate my random password:

The xdebug.profiler_output_dir lets you change the folder that xdebug saves the profiling output files to - make sure that the folder you specify here is writable by the user that PHP is executing as.If you've got a lot of profiling to do, you may want to consider changing the output filename, since xdebug uses a rather unhelpful filename by default. The property you want to change here is xdebug.profiler_output_name - and it supports a number of special % substitutions, which are documented here. I can recommend something phpprofile.%t-%u.%p-%H.%R.%cachegrind - it includes a timestamp and the request uri for identification purposes, while still sorting chronologically. Remember that xdebug will overwrite the output file if you don't include something that differentiates it from request to request!

Phpstorm Xdebug Profiler Snapshot

With the configuration done, we can now move on to actually profiling something :D This is actually quite simple. Simply add the XDEBUG_PROFILE GET (or POST!) parameter to the url that you want to test in your browser. Here are some examples:

Adding this parameter to a request will cause xdebug to profile that request, and spit out a cachegrind file according to the settings we configured above. This file can then be analysed in your favourite editor, or, if it doesn't have support, an external program like qcachegrind (Windows) or kcachegrind (Everyone else).

If you need to profile just a single AJAX request or similar, most browsers' developer tools let you copy a request as a curl or wget command (Chromium-based browsers, Firefox - has an 'edit and resend' option), allowing you to resend the request with the XDEBUG_PROFILE GET parameter.

If you need to profile everything - including all subrequests (only those that pass through PHP, of course) - then you can set the XDEBUG_PROFILE parameter as a cookie instead, and it will cause profiling to be enabled for everything on the domain you set it on. Here's a bookmarklet that set the cookie:

(Source)

Replace insert_secret_key_here with the secret key you created for the xdebug.profiler_enable_trigger_value property in your php.ini file above, create a new bookmark in your browser, paste it in (making sure that your browser doesn't auto-remove the javascript: at the beginning), and then click on it when you want to enable profiling.

Was this helpful? Got any questions? Let me know in the comments below!

Sources and further reading

Phpstorm Setup Xdebug

• PHPStorm-specific documentation, guides, and tutorials:
  • Enabling Profiling with Xdebug in the PHPStorm documentation
• Webgrind - an easy-to-setup web-based gui for xdebug profiling analyser by Joakim Nygård
• kcachegrind - The original (as far as I know) profile analysis tool. Should be available in most distributions' default repositories under something like kcachegrind or similar.
• XDebug Snippets by jtdp