The Golden Ratio

I just got introduced to Xdebug, a debugging and profiling tool for PHP. Previously I’ve tried the Zend profiler, but I never got it working properly.

One of the good things about Xdebug was how easy it was to install. First step, assuming you already have PHP and Apache installed, is to install the php-dev package. We also need to install Pear, since Xdebug is installed through that instead of the usual aptitude system. Installing these two packages is done with

sudo aptitude install php5-dev php-pear

With that done it is time to install Xdebug. Since we’re using Pear for the installation the install command is a bit different from the usual procedure. The command used for installation this time is

sudo pecl install xdebug

After that we need to make sure that PHP knows that we want to use Xdebug. To do this we need to edit the php.ini file (found with sudo vim /etc/php5/apache2/php.ini). Here you add

zend_extension="/usr/lib/php5/20060613+lfs/xdebug.so"

to the end of the php.ini file. The path might be a little bit different for you. In that case you can see the path to use among the last lines produced by the Xdebug install command. If that doesn’t work you can find it by calling

find / -name xdebug.so 2> /dev/null

Once that line has been added to the php.ini file we need to restart Apache for it to be enabled.

sudo apache2ctl restart

We’ve now installed and enabled Xdebug.

The two first features you’ll notice with Xdebug is the improved error reporting. Without doing anything extra the var_dump has been vastly improved, The output from it now looks like this image.

Figure 1: Xdebug’s improved var_dump

As you see the new format is formatted in a readable fashion, has syntax highlighting and contains some basic information about the variable types as well. If that wasn’t enough the PHP Error reporting has been improved as well. Instead of the simple one line text message you now get

Figure 2: Xdebug’s improved PHP Error display

As you see it includes the standard error line, but it now has trace information with both command and where in which files the commands where called. It also has a bit nicer styling, which is always a bonus. A thing to note with the improved error reporting of Xdebug is that it should be turned of on pages open to the public, since the trace contains information about the application that the general public shouldn’t see.

Those are the first and easiest improvements available with Xdebug, but the biggest improvement is still to come – the profiling aspect of Xdebug. When creating big applications it is important to see where the slow downs are, especially if these applications have high traffic. The traditional way to do this is to add profiling code the the parts that are slow. This will give information about how much execution time each part of code takes. The problem with this approach is that it might be hard to figure out where the bottlenecks are, and to time each function call within a section you need a lot of profiling code. But with Xdebug that is taken care of for us.

To enable the profiling part of Xdebug the following lines need to be added to the php.ini file.

xdebug.profiler_enable=1
xdebug.profiler_append=1
xdebug.profiler_output_dir="/var/www/logs"

The first line enables the profiling part of Xdebug, the second line ensures that information is appended to the output file and the last line dictates the path to save the profiling files.

After restarting Apache with these changes a new file will be added to the specified path each time a php page is loaded from your local server. This will create a lot of files, but if you delete them often enough (or create a script to delete them on each logout for instance) this shouldn’t be a problem. It is possible to enable/disable the profiling from PHP using ini_set, which might be preferable. The files in the directory will have a name similar to cachegrind.out.1234, where the last number part is the process id of the Apache process that created the file.

The content of the profiling files is pretty cryptic and hard to read, so we need to find a program to filter and make this information understandable. Luckily there is just a program for that, called Kcachegrind. It is a KDE program, so if you’re using standard Ubuntu like I am you need to install a couple of extra KDE libraries to get it working. I looked for a suitable Gnome version of it, but couldn’t find anything that compared. Installation is done with

sudo aptitude install kcachegrind graphviz

After that you can start it by calling kcachegrind. Once inside Kcachegrind you can open your profiling files to see the information they contain. This will give you information about the order each function was called, how much time and memory they used and much else. It is a lot of useful information once you figure out what it all means. The easiest way to do that is to play around with the various views available when parsing an easy script that you have control over. That way you can easily see how changes you make affect the profile information.

As I get more comfortable with it myself I’ll post an update on how to get the most of out the information found.

Technorati Tags: php, xdebug, profiling, debugging, linux