HOME >> Need For Speed
      One of the greatest advantages when using PHP is obviously speed. PHP4 is in general fast enough for dynamic web content generation, and in most cases you can't even think of anything faster than it. But when you have to face lots of accesses, heavy applications, narrow bandwidth, or other factors that can create performance bottlenecks, you may ask yourself if you can do anything to make things work better. This article explains what you can do to further improve php performance, and how to make your users' browsing experience even more pleasant.

First of all, code optimization...

      Apart from writing clean and clear code, there's something that can optimise your code for you. It's the Zend Optimizer, (available under the Zend Optimizer license, since it's not released under the GPL) from Zend Technologies (the people that brought us the blazing fast PHP engine). It "simply" goes over the intermediate code generated by the Zend Engine and optimizes it for faster execution. Tweaking code sometimes can bring you to unreadable code, and this is not what you want to find when making changes to your nearly forgotten 3-years-old PHP application... ;-) . You will notice that complex PHP sources suddenly will benefit from Zend Optimizer, so I suggest you to use it as long as it doesn't produce strange incompatibilites with your code (never found one though). Installing the Zend Optimizer is really easy. Just download the precompiled library for your platform, add the following two lines in your php.ini, restart your webserver, and... That's it!


      Ooops... I said two lines and you find three. In fact the third line is optional, but it seems that disabling this zend_loader speeds up a bit the Optimizer, so it's worth a line in your php.ini. Pay attention: you can disable the zend_loader only if you don't use the Zend Encoder Runtime, which will be discussed later.

Want more speed? Let's cache...

      If you need extra speed for your heavy PHP application, then the solution probably is caching. There are some possible solutions out there. I tried Zend Cache (trial-version), APC, and Afterburner Cache.

      The above are "caching modules". They store and intermediate coded version of your PHP sources inside the webserver's memory, the first time your .php file has been requested, and they serve subsequent requests with the "compiled" version. This approach can really boost your application's performance, since this minimizes access to disk (the code has been already read and parsed), and also works in RAM, which makes things a lot faster. Obviously the caching module will notice of changes in your PHP sources, and will redo the job again, so your users won't get pages coming out of stale cached PHP code. Caching modules are really well-suited for heavily loaded sites, since they can decrease your server's load and make PHP work even faster. But, which one should I choose?

      Zend Cache is a commercial product from Zend Technologies. It really does what they say! You can notice the speed improvement in heavy PHP pages just after the first run, and the server also has more free resources.

      Afterburner Cache is a free caching module available from Bware Technologies. Currently in beta, it seems to do same the same things that Zend Cache does. It can't push performance up as Zend Cache does (yet), and it doesn't work with Zend Optimizer yet.

      APC (Alternative PHP Cache) is another free caching module available from Community Connect. Seems stable enough for production use, and also seems to speed up things a lot. Beware, We haven't found a official benchmark yet, so we had to test them with some of our applications. As always, your mileage may vary.

      Web Content Compression (how to make your visitors even happier)
Now that you have pushed your PHP application's performance to the top :-) it's time to work on one of the other factors that can make your site seem slow to visitors: download speed. If your application is used in your Intranet, with all of your clients using a 100Mb/s ethernet connection to the server, this probably may not be a problem. But if you have to serve slow modem clients, then the solution is content compression. Most browsers support content compression with gzip, according to IETF standards. This means that you can send web content to a browser compressing it with gzip, and the browser will transparently uncompress the data and make the page visible to the user. There are different methods you can use to compress web content.

      mod_gzip is an Apache module available for free from Remote Communications that can compress static web content to browsers that support this kind of Content-Encoding. It really works fine with most of the static content, and you can easily compile it with apache (or use it as a DSO). Folks at Remotecommunications say that it could compress dynamic content also, coming from mod_php, mod_perl, or mod_whatsoever :-). I tried and tried, but this seems not to work. I saw many postings in mod_gzip mailing list, and it seems that in the next release (, I suppose) this will be fixed. Meanwhile, you can use it for the static part of your site.

      But we want to compress the dynamic content also, so we have to find other ways. A solution is to use class.gzip_encode.php, a PHP class that you can use to compress your pages by calling some of its functions at the very beginning and end of your PHP scripts. A site wide solution is to call these functions from the auto_prepend and auto_append directives of your php.ini file. This works fine, but obviously introduces a bit of overhead in heavily loaded sites. For details on how to use it, look inside the class code (at least you need PHP compiled with zlib support). It's very well commented and the author tells you everything you need to know.

      In PHP 4.0.4 a new output buffer handler has been introduced, ob_gzhandler, which does just the same thing as the above class. But instead of the previous class, you can put this in your php.ini, using the following syntax:

output_handler = ob_gzhandler ;

      This makes PHP activate output buffering and compress anything it is sending out. If you have particular reasons for not putting it here, you can always change the default behaviour (not compress) with a .htaccess file in your to-be-compressed PHP source directory, using this syntax:

php_value output_handler ob_gzhandler

... or even call it from your PHP code, in this way:


      The output buffer handler approach really works fine, and doesn't introduce particular overhead on the server. We really suggest you to use this approach. Your 28.8K modem users will think that they suddenly got a ISDN line for Christmas, and probably will offer you a drink next time they meet you ;-) . Pay attention: Netscape Communicator doesn't like compressed images, and it will display them as broken. So you have to disable compression for jpegs and gifs, unless your users are all using Internet Explorer (which works just fine). In general compression should work for all other files, but I suggest you to test each browser, particularly if you use "strange" plugins or viewers.


Using the technologies explained in this article you can greatly improve the performance of your site, but please be aware that:

- PHP may or may not be your bottleneck. Monitor carefully every object tied to your application (databases, for example).
- You can't push a webserver performance over its top. So, before blaming PHP or its caches, think if it's time to upgrade your server or even think at a load balanced environment (which may cost lots of money).
- Don't understimate content compression. Even if you see speedy PHP applications on your 100Mb/s lan connected desktop, poor modem users don't, and will blame you for 100Kb html pages.