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. In this article I'll explain 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...
No, I'm not going to tell you again that you have to write clean and clear code, since
everyone knows it, and if you're looking for speed then you probably already tweaked something
in your PHP sources. However, there's something that can do this dirty job for you. It's the
Zend Optimizer, available for free (you have to agree to the Zend Optimizer license, since it's not
released under the GPL) from
Zend Technologies
the people that brought us our blazing fast PHP engine). It "simply" goes over the intermediate code generated by
the Zend Engine and optimizes it for faster execution. I said "dirty job" since we all know
that 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 sudden 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!
zend_optimizer.optimization_level=15
zend_extension="/path/to/ZendOptimizer.so"
zend_loader.enable=Off
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, than probably the solution 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 (yes, the ones that brought us the PHP engine
and the Zend Optimizer for free...). 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. Unfortunately
you have to pay for this, but in some cases it's well worth the price.
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, but it's free,
and my compliments go to bware folks for this nice job.
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, I haven't found a
official benchmark yet, so I had to test them with some of my applications. As always, your mileage my 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 (1.3.14.6f, 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.
Since PHP folks' duty is to surprise me every day, I read
here
an interesting article from our friend Zeev Suraski (shame on you if you don't know this PHP guru ;-) ) about
output buffering with PHP. It also tells us that 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:
ob_start("ob_gzhandler");
Output buffering and compression is discussed also in
this
PHPBuilder.com article from Luis Argerich. The output buffer handler approach really works fine, and doesn't introduce particular
overhead on the server. I 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.
Enough Speed For Today. Now Some Other Useful Stuff...
Yesterday (24 January 2001) Zend Technologies opened their online store. They're selling some interesting
PHP-related products. Among this, the previous mentioned Zend Cache, Zend Encoder (in a few words a "compiler"
for PHP code that generates encoded classes that you can sell to your customers. The webserver where these
classes will run needs the Zend Encoder Runtime to decode the scrambled code), Zend Ide (an IDE for PHP with
lots of powerful features), and a few Support Services that can help a desparate PHP developer).
Conclusion
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.
Best Regards
-- Draxx