Linux programming to improve PHP implementation speed full raiders analysis

One of the advantages of PHP is that the speed of the general Web application, can be said to be enough. However, if the site's access is high, with narrow or other factors causing the server performance bottlenecks, you may have to think of other ways to further improve PHP speed. This article will explain how to do this in several ways, making it more "cool" for users to browse.

Code optimization

How to write cleaner code, which I think everyone knows, when you need speed, you may have done a lot of work on the optimization of PHP source code, here is that this cumbersome work can be put to other tools to complete. This is Zend Optimizer, which can be obtained free of charge from the Zend Technologies website (http://www.zend.com/). The principle is simple, by detecting the intermediate code generated by the Zend engine, and optimizing it to achieve higher execution speed. I think that optimizing code is a rather cumbersome task, and optimized code may become difficult to understand, especially when you put down the PHP program for a period of time, suddenly customers ask you to make some changes, you may not understand yourself; So I suggest that you do this optimization work with Zend Optimizer when the source code in PHP is more complex, and the advantage is that it doesn't make your coding complex and difficult to understand.

Installation of Zend Optimizer is very simple. Just follow the platform you use, download the relevant precompiled library, and add two lines to your php.ini, restart your Web server!

zend_optimizer.optimization_level=15
zend_extension="/path/to/ZendOptimizer.so" zend_loader.enable=Off

You may be a little strange, not to say two lines, how to become three lines. But the third line is optional, and it seems that banning the zend_loader will make the optimization faster, so add the line to your php.ini file. Note that Zend_loader can be banned only if you do not use the Zend Encoder Runtime, the Zend Encoder Runtime, which is also mentioned below.

Will it be faster? Use cache (buffer)!

If your PHP application still needs to be faster, the next option is to buffer. There are several different ways to achieve this. I tried my own Zend cache (evaluation version), APC and Afterburner cache.

All of the above mentioned are "buffer modules". They are similar in principle, when the PHP file is first requested, by storing the intermediate code of your PHP source code in the Web server's memory, for the same request in the future, directly provide the "compiled" version in memory. Because it minimizes access to the disk, this approach does greatly improve PHP performance. More conveniently, when your PHP source code is modified, the buffered module can detect these changes and reload them, so you don't have to worry about the client getting the old version of the program. These buffer modules are really good, but which one should I choose? Here are the following:

Zend Cache is a commercially available product for Zend Technologies (it is also a company that provides us with PHP engines and Zend optimizer for free). It's really good. After the first run, you can obviously see the speed of PHP has been greatly improved, the server has more free resources. The disadvantage is that you have to pay to buy it, but in terms of cost-effective, it is still very worthwhile.

Afterburner Cache is a free buffer module provided by Bware Technologies (bwcache.bware.it). Currently only beta, it does work looks similar to the Zend cache, but the performance of the improvement is not as Zend cache, and the existing version can not work with Zend Optimizer, but it is free.

APC (Alternative PHP Cache) is another free module provided by Community Connect (apc.communityconnect.com). Its work is very stable, speed also has a lot of improvement, it should be noted that I have not found an official test data, these are only in my application for testing, so can not be the next conclusion.

Through the above two methods, I believe that your PHP application performance has been greatly improved, now the other aspect to consider: download speed. If your application is running within the company, all customers use 100MB/S Ethernet to connect to the server, which may not be a problem, but if your client is connected by a slow modem, you should consider using the content compression method.

According to the IETF specification, most browsers support gzip content compression. This means that you can use gzip to compress the content of the web before it is sent to the client's browser, and the browser will extract the data automatically when it is received, and make the user see the original page. Similarly, there are several different ways to compress the content of a Web page. Mod_gzip is a free Apache module provided by Remote Communications (http://www.phpbuilder.com/columns/www.remotecommunications.com), It can compress a static web page. It works well and you just have to compile it with Apache (or use it as a DSO). Remotecommunications people say it can also compress dynamic content, including mod_php, Mod_perl, and so on. But I tried it, and it didn't seem to be all right. I learned from the Mod_gzip mailing list that this bug will be corrected in the next release (I think it should be a 1.3.14.6f version). But you can still use it as a compression for static content.

But we also want to compress the dynamic content, so we have to find another way. One way to do this is to use Class.gzip encode.php (http://leknor.com/code/) to compress the content of your pages as long as you call the PHP class at the beginning and end of your PHP script. If the entire site requires such compression, you can call these functions in the Auto_prepend and auto_append in your php.ini file. It works fine, but it obviously brings a bit of overhead on a heavily loaded site. To learn more about how it works, take a look at its class code (you'll need to add zlib support at least when compiling PHP). The author's instructions are also very detailed and you can get anything you need to know.

Recently, I also saw an article about PHP output buffering. What it says is that PHP4.0.4 has introduced a new method of output buffering--ob_gzhandler, which is the same as the class described above, but the difference is that you just use the following syntax in your php.ini:

output_handler = ob_gzhandler ;

This activates the output buffering function of PHP and compresses everything it sends. For some particular reason, if you don't want to set it here, change the default setting only if you need it (not compressed), just modify it in the PHP source directory that needs to be compressed. htaccess file on the line, using the syntax as follows:

php_value output_handler ob_gzhandler

or call it directly in your PHP code, in the following way:

ob_start("ob_gzhandler");

This output buffering process is good and does not incur additional overhead for the server. I highly recommend that you use this method. Its changes can be illustrated in the following example, if the customer is using a 28.8K modem, after this processing, he will think suddenly replaced by an ISDN access. The point to note is that Netscape Communicator does not support image compression, so it will not be displayed. So unless your client uses Internet Explorer entirely, you must disable compression of JPEG and GIF images. Other file compression should be fine, but I recommend that you test it, especially if the browser uses an unusual plugin or a browser that is less popular.

Zend Technologies's Online store opened 24 this January and sells interesting PHP-related products. Including the aforementioned Zend Cache,zend encoder (in short, PHP code compiler, you can generate compiled classes, so you can sell to customers without worrying about leaking source code. On a Web server that needs to run these classes, it will be decoded using Zend Encoder runtime, Zend Ide (an integrated development environment for PHP with a lot of powerful performance), and support services for PHP developers.

Conclusion

Using the techniques mentioned in this article, you will be able to greatly improve the performance of your site, but note the following points:

1. Bottlenecks may not be in PHP, you need to look at each object in the application (such as a database).

2. There is a limit to the performance of a Web server, so don't assume that poor performance is the cause of PHP, it can be a lot of traffic, your server needs to be upgraded, or consider using a load-balanced system (which will cost a lot of money).

3. Do not think that content compression is not important, in the 100mb/s LAN, your PHP application may be very good performance, but to consider the use of slow modem users.