We at codecentric are not only leaders in Java performance, but support our clients on a variety of software development challenges.
I posted in a previous entry about Comparison of PHP and Java. I said that PHP mainly lacks appropriate tooling to develop debug and maintain. To be fair with PHP this posting will today describe how to profile PHP applications to tune performance. We will see how this tooling compares to the Java ones.
For Java developers JProfiler should be a well known tool for profiling and analyzing performance of Java applications. De equivalent in PHP is called Xdebug Xdebug + CacheGrind. Xdebug is recording the calls to the PHP scripts, while WinCacheGrind is then used afterwards to evaluate the collected Data. In this example we are goung to profile a command line call of the symfony Framworks. Because I am commiter for this framework, I use Xdebug from time to time to ensure a good nonfunctional quality.
First you need to download the appropriate ‘.dll’ (or ‘.so’ for Linux) extension from the Xdebug website and put it to the other extensions into the ‘php/ext’ directory. To enable tat extension you need to add Xdebug to the ‘php.ini’ Xdebug and tell it where it should put the profiling results:
Take care to edit the correct ‘php.ini’ file. There is one for the command line calls usually found in the PHP directory and another one in the Apache directory for the PHP processes spawned by Apache. Additionally you need to create the target directory first because Xdebug will not create it if it is not existing yet.
Invoking ‘php -m’ from the command line should output something including:
Now we are going to profile a simple call. For example one to the symfony sandbox to create an application:
php symfony generate:app codecentric
After this call has ended an 8MB ‘cachegrind.out.4896’ been created for us. It now can be loaded using WinCacheGrind, which looks like this:
Unfortunately WinCacheGrind has only limited functionality. KCacheGrind allows some more settings and graphical representation of the data, but also is not as complete as the Java tools we usually use. It also does not contain a memory view, which might be due to the fact that the PHP memory management is pretty messy. Quite useful though is is the timing information displayed.
On the ‘Overall’ tab you can find code which took in sum the most time of your application. This is usually the code where you can make the easiest improvements. For the symfony task we can find here the following:
Function : sfFinder->search_in
Avg. Self : 0,2ms
Avg. Cum. : 5,1ms
Total Self: 127ms
Total Cum.: 3214ms
Calls : 629
you can see that the search_in function takes an average of 0,2ms, but methods invoked by it add another 5,1ms in average. Because this function is called 629 times, this gives you the total time spent. A good candidate for checking if it really should be called that often, and if yes, if a single call can be made slightly faster.
As you can see, also without a lot of expertise for performance issues, one can use above described tools to optimize PHP application performance. Perhaps in some time in future PHP and its tools will be as sophisticated as it is already today status quo in Java.