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:
sudo apt install php-debug
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:
<?php
phpinfo();
?>
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:
[xdebug]
xdebug.remote_enable=1
xdebug.remote_connect_back=1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_autostart=true
xdebug.profiler_enable=false
xdebug.profiler_enable_trigger=true
xdebug.profiler_enable_trigger_value=ZaoEtlWj50cWbBOCcbtlba04Fj
xdebug.profiler_output_dir=/tmp
xdebug.profiler_output_name=php.profile.%p-%u
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:
dd if=/dev/urandom bs=8 count=4 status=none | base64 | tr -d '=' | tr '+/' '-_'
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!
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:
https://localhost/carrots/moon-iter.php?XDEBUG_PROFILE=ZaoEtlWj50cWbBOCcbtlba04Fj
https://development.galacticaubergine.de/register?vegetable=yes&mode=plus&XDEBUG_PROFILE=ZaoEtlWj50cWbBOCcbtlba04Fj
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:
javascript:(function(){document.cookie='XDEBUG_PROFILE='+'insert_secret_key_here'+';expires=Mon, 05 Jul 2100 00:00:00 GMT;path=/;';})();
(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-specific documentation, guides, and tutorials:
- 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