Detailed introduction to PHP application speed-up aspects

我们都知道，速度快是PHP最大的优点。一般情况下PHP总是具有足够的速度支持Web内容动态生成，许多时候你甚至无法找出比它更快的方法。

　　然而，当你不得不面对庞大的访问量、高负荷的应用、有限的带宽以及其他各种带来性能瓶颈的因素时，你可能会问问自己是否可以做点什么让网站运行得更好。或许只要加上一个很不起眼的免费模块，你的PHP应用性能以及Web服务器响应速度就会有显著的改善。

　　本文讨论的就是如何进一步提高php应用的性能，给用户以更美妙的浏览感受。本文分三个方面(代码优化、缓存、内容压缩)阐述提高 PHP应用性能的各种技术，并介绍各个领域的知名产品。

　　代码优化

　　首先我们来看看代码优化。注意，这里的代码优化可不是指把代码写得更加美观漂亮，因为这恐怕已经是众所周知没有必要继续讨论了;另外，如果你已经考虑到了速度问题，很可能你早就对PHP的源代码作了一些优化。

　　不过，有些工具却能够自动地帮助我们完成这些繁杂的工作，如Zend Optimizer就是这样一个工具。 Zend Optimizer可以从Zend Technologies免费得到，但你必须同意它的许可约定，注意它不是以 GPL方式发行。Zend Optimizer获取由Zend Engine运行时编译生成的中间代码，并对它进行优化，从而使得中间代码具有更快的执行效率。

　　Zend Optimizer的安装方法非常简单，你只需下载为自己所用平台提供的预编译版本，把下面两行代码加入到php.ini，然后重新启动Web服务器即可：

　　zend_optimizer.optimization_level=15

　　zend_extension="/path/to/ZendOptimizer.so"

　　zend_loader.enable=Off

　　这里额外增加的第三行代码是可选的。禁止zend_loader似乎能够让Zend Optimizer的速度更快一点，所以在php.ini中加上这行代码是值得的。注意：只有当你不使用Zend Encoder Runtime时，你才可以禁用zend_loader。

　　缓存

　　如果你想要让自己庞大的PHP应用有更好的性能表现，采用缓存也是一种很好的方法。现在已经有许多缓存方案可供选择，其中包括：Zend Cache，APC，和Afterburner Cache。

　　所有这些产品都属于“缓存模块”。当第一次出现对.php文件的请求时，它们会在Web服务器内存中保存 PHP的中间代码，此后就用“经过编译”的版本响应后继的请求。这种方法确实能够改善应用的性能，因为它使得磁盘访问量减低到了最少的程度(代码已经读取和解析)，代码直接在内存中运行使得服务器响应请求的速度大大提高。

　　当然，缓存模块还会监视PHP源文件的变化，必要时重新缓存页面，从而防止了用户得到的页面仍旧由过时的PHP代码生成。由于缓存模块能够明显地降低服务器的负载、提高PHP应用的响应效率，因此它们非常适合于负载较大的网站使用。

　　如何选择这些缓存产品

　　Zend Cache是Zend Technologies公司的商业软件，而Zend Technologies就是前面提到的那个为我们提供PHP引擎和免费Zend Optimizer的公司。Zend Cache确实是名不虚传!对于大型的 PHP页面，你可以感觉到第一次运行之后速度就会有所提高，而且服务器也会有更多的可用资源。遗憾的是这个产品并不免费，不过在有些情形下它仍旧是物超所值。

　　Afterburner Cache是来自Bware Technologies的免费缓存模块，当前这个产品还是Beta版。 Afterburner Cache的做法看起来与Zend Cache差不多，但它对性能的改善程度(还)不能与 Zend Cache相比，而且它还不能与Zend Optimizer一起工作。

　　APC是Alternative PHP Cache的缩写，它是来自Community Connect的又一个免费缓存模块。这个产品已经具有足够的稳定性供正式场合使用，而且它看起来也能在很大程度上提高响应请求的速度。

　　内容压缩

　　前面我们讨论了几种提高PHP应用性能的方法，下面来看看使得浏览者感到网站速度太慢的另外一个重要因素：下载速度。如果PHP应用在内部Intranet上运行，而且每一台客户机都以100 MB/s的速度连接到服务器，那么下载速度应该不是什么问题。然而，如果服务器还要为慢腾腾的Modem用户提供服务，那么值得考虑内容压缩。

Most browsers support gzip for content compression according to IETF standards. This means that you can gzip the content and send it to the browser, which will decompress the data before displaying the page, and the entire process is completely transparent to the user. As for server-side content compression, many different methods are available.

For example, the free Apache module mod_gzip from Remote Communications has the ability to compress static web content for browsers that support this type of content encoding. For the vast majority of static web content, mod_gzip works very well. mod_gzip can be easily compiled into Apache and can also be used as a DSO. According to Remote Communications, mod_gzip can also compress dynamic content from mod_php, mod_perl, etc.

I tried again and again, but it still doesn’t seem to work. I read many forums and articles about mod_gzip, and it seems that this problem is expected to be solved in the next version of mod_gzip (probably 1.3.14.6f). Until then, we can use mod_gzip in the static parts of the website.

However, sometimes we really need to compress dynamic content, so we must find other ways. One way is to use class.gzip_encode.php, which is a PHP class that can be used to compress the content of the page by calling certain functions of the class at the beginning and end of the PHP script. If you want to implement this solution at the website level, you can call these functions from the auto_prepend and auto_append directives in the php.ini file.

Although this method is effective, it undoubtedly brings more overhead to high-load websites. For detailed instructions on how to use this class, see its source code. Its source code description is quite complete, and the author tells you everything you need to know.

PHP 4.0.4 has a new output cache handler ob_gzhandler, which is similar to the previous class, but its usage is different. The content to be added to php.ini when using ob_gzhandler is as follows:

output_handler = ob_gzhandler ;

This line of code causes PHP to activate output caching and compress everything it sends out. If for some reason you don’t want to add this line of code to php.ini, you can also change the default server behavior (no compression) through the .htaccess file in the directory where the PHP source file is located. The syntax is as follows:

　php_value output_handler ob_gzhandler

Or call it from PHP code, as shown below:

ob_start("ob_gzhandler");

The method of outputting cache handles is indeed very effective and does not place any special load on the server. However, it must be noted that Netscape Communicator has poor support for compressed graphics, so unless you can ensure that all users use IE browser, you should disable compressed JPEG and GIF graphics. In general, this compression works for all other files, but it is recommended that you test it separately for each browser, especially if you use special plug-ins or data viewers. This is especially important.

Using the various techniques introduced earlier, you can significantly improve the performance of your website, but you should pay attention to the following:

PHP may or may not be the performance bottleneck. Be sure to carefully observe every factor related to application performance, such as databases, etc.

Simply using the technology in this article can only improve the performance of the web server within a certain limit. So before blaming PHP and its cache, you might as well see whether you should upgrade the server and whether load balancing technology can be introduced (the latter requires a larger investment).

Don’t underestimate the power of content compression. Although you will see that the Web application responds very quickly under a 100 MB/s LAN connection, users using a Modem connection will not. They will only complain that your 100 Kb HTML page is too large.

I hope this article’s introduction to PHP can help you.

Detailed introduction to PHP application speed-up aspects_PHP tutorial