PHP Performance Profiling

Techniques for learning where the bottlenecks are in your PHP-based Web application.
Profiling A Live Site

To get the best understanding of how your PHP implementation runs under real conditions, you should do the profiling in an environment as close as possible to the real thing. Real data and many real or simulated client connections are helpful. You can create this environment by making a duplicate of your site and running HTTP benchmarking software or even using a couple of shell scripts and Wget to simulate user loads. Alternatively, you can do the profiling right on your live site.

As you've seen, using the profiling features of APD in your scripts causes the Web server to write out text files for every script access. That's obviously a very bad thing if you're trying to profile a live site, because data is dumped out faster than you can deal with it. Besides, it causes a slowdown on the server if your site has a lot of visitors--and if it didn't, you wouldn't be profiling it, would you? A useful little trick to get around the problem is to activate profiling only for page requests coming from your specific IP address. Doing so allows you to browse the live site and produce profile information without any action being taken on requests by other users.

This situation actually is pretty trivial to implement. Simply wrap the invocation of apd_set_pprof_trace() in a check for the requesting IP address, as shown below. Then, only your nominated client addresses cause the script to go into profiling mode:

        $DEBUGIPS = array('','');
        if(array_search($_SERVER[REMOTE_IP], $DEBUGIPS)) {
Where to Go from Here?

What now? Optimize your code, of course. I'm not going to tell you how to do that here, because it's way beyond the scope of this short article. But, at least now you have some insight into the internal workings of your application and won't be wasting time optimizing parts of your code that aren't really a problem. And when you do make changes, you have a benchmark against which you can test your code to see how the changes affect performance and efficiency.

Jonathan Oxer is the founder and Technical Director of Internet Vision Technologies, an Australian Web application development agency with clients around the world. He also is a Debian developer, current maintainer of apt-cacher and was organizer of the Debian Mini-Conf in Perth in January 2003 in association with Linux Conf Australia, where he also presented one of the technical papers. His first book, How to Hire a Web Developer and Stay Sane, will be published soon. His second book, The Debian Universe is being written live on-line, and his third and fourth books (How to Deploy Web Applications and Stay Sane and Disaster Proofing for Small Networks) already are underway.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


Valeriu Palos's picture

Great article! APD is a great way to have a local and accurate profiling of your code. That is very useful in large applications since you can concentrate on a specific subsection of the code for optimization without being distracted by other stuff.

However, many times I find that using XDebug+Valgrind is a very good idea, because it can give you a good picture of how your entire application behaves and what are its most expensive (or critical) modules. Also the XDebug method is also the most unobtrusive I think (you only need very minor changes in your code for this to work).

apd not working from within apache server

mukul's picture

HI, I am a newbie in APD, require your help to profile our PHP application. I have installed APD 1.0.1 on a Linux box and I am able to profile sample php scripts by firing them from shell as “php samplescript.php

Re: PHP Performance Profiling

Anonymous's picture

Another nice way to analyze the trace file is by doing
$ pprof2calltree -f [pprof tracefile]
and then open the resulting file with KCachgrind

installation of APD not so easy

misterff's picture

Installation of APD on my Debian system doesn't turn out to be so easy.
I just upgraded to Apache 2.2.0 and PHP5. I tried to install with the pear command, which gave me the following:

$ pear install apd
PHP version >= 5.0.0RC3-dev is required
apd: Dependencies failed

I also tried with:

$ apt-get install php5-apd

But php5-apd doesn't exist so I installed php4-apd which doesn't work.

Any idea's?

RE: installation of APD not so easy

Rene's picture

I had the same problem installing apd on my gentoo machine.
It won't help you, but after the problems I had, I found out the for Gentoo apd is in portage (pecl-apd)
There might be some dependency problems, but once you fix those, apd works.

APD is a pecl package

Stefano Canepa's picture

I found out that to install apd on PHP 5 you need to use pecl install apd command and not pear install apd

apd install errors

Anonymous's picture

has anyone solved this problem yet? tried pecl install apd, but no pecl command available. tried to install pecl, but instructions are too ambiguous -- Does apd REALLY require php v5.0 or is this a bug in the installation software?

After using "pecl install

Anonymous's picture

After using "pecl install apd" and putting where php.ini wanted it there were a few more php.ini directives to add before the module showed up on my phpinfo page. See:

Check the link

jostmart's picture

I managed to install efter looking trough this page: