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
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 '+/' '-_'
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:
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
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:
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
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
- XDebug Snippets by jtdp