One of the advantages of PHP is that it is fast and is sufficient for general website applications. However, if your site has high traffic, narrow, or other factors that make the server performance bottleneck, you may have to think of other ways to further improve the speed of PHP. This article will show you how to do this in several ways, making it more "cool" for users to browse.
Code optimization
I don't want to tell you how to write cleaner code here again, and I think everyone knows that you might have done a lot of work on the PHP source code optimization when it needed speed, and it was suggested that this cumbersome work could be done by other tools. This is Zend Optimizer, which can be obtained free of charge from Zend Technologies's website (http://www.zend.com/). Its rationale is simple, by detecting the intermediate code produced by the Zend engine and optimizing it to achieve higher execution speed. I think optimizing the code is a tedious task, and the optimized code can become difficult to understand, especially if you drop the PHP program for a while and suddenly the customer asks you to make some changes, and you may not understand it yourself;-). So I suggest you do this optimization work with Zend Optimizer when the source code of PHP is more complex, the advantage is that it will not make your coding complicated and difficult to understand.
Installing the Zend Optimizer is very simple. Just download the relevant precompiled library based on the platform you're using, and add two lines to your php.ini and 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 this zend_loader will make the optimization faster, so add this line to your php.ini file. Note: Only when you do not use the Zend Encoder runtime, you can prohibit Zend_loader, about Zend Encoder runtime, will also be mentioned below.
Is it going to be faster? Use cache (buffer).
If your PHP application needs to be faster, the next approach is buffering. There are several different ways to achieve this. I have tried the Zend Cache (Beta version) myself, APC and Afterburner cache.
All of the above mentioned are "buffer modules". They all have the same principle, when the PHP file is first requested, by storing your PHP source code intermediate code in the Web server's memory, for the same request in the future, directly provide in-memory "compile" version. Because it minimizes access to the disk, this approach does greatly improve PHP performance. More convenient is that when your PHP source code changes, the buffered module can detect these changes, and reload the same, so you don't have to worry about the customer is getting the old version of the program. These buffering modules are really good, but which one should I use? Here are a few separate sections:
Zend Cache is a commercial product of Zend Technologies (it is also free for us to provide PHP engines and Zend optimizer companies). It's really good. After the first run, you can obviously realize that PHP has been greatly improved, and the server has more free resources. The downside is that you have to pay to buy it, but it's worth it for the price.
The afterburner cache is a free buffer module provided by Bware Technologies (http://bwcache.bware.it/). It's just a beta version, and it looks like Zend cache, but the performance is not as high as Zend cache, and the existing version doesn't work with Zend Optimizer, but it's free.
APC (Alternative PHP Cache) is another free module provided by Community Connect (http://apc.communityconnect.com/). Its work is very stable, the speed also has a lot of improvement, it is important to note that I have not found an official test data, these are only in my application test, and therefore cannot next conclusion.
Compression of Web content (making your customers more "cool")
After two of the above methods, I believe that your PHP application performance has been greatly improved, now from another aspect to consider: download speed. If your app is only running within the company, all customers use 100MB/S Ethernet to connect to the server, which may not be a problem, but if your customer has a slow modem connection, you should consider using the content compression method. Depending on 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 customer's browser, and the browser automatically extracts the data when it is received, and lets the user see the original page. Similarly, there are several different ways to compress the content of a Web page.
Mod_gzip is a remote Communications (http://www.phpbuilder.com/columns/ www.remotecommunications.com) is an Apache module that can compress static Web pages for free. It works well and you just have to compile it with Apache (or use it as a DSO). Remotecommunications says it can also compress dynamic content, including mod_php, Mod_perl, and others. But I tried it and it didn't look right. I learned in Mod_gzip's mailing list that this bug will be fixed in the next release (I think it should be version 1.3.14.6f). However, you can still use it for static content compression.
But we also want to compress 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/) and simply call the PHP class at the beginning and end of your PHP script to compress the contents of your page. If this compression is required for the entire site, you can call these functions in Auto_prepend and auto_append in your php.ini file. It works well, but on a heavily loaded site, it obviously brings a bit of overhead. To learn more about how it works, take a look at its class code (you need to add zlib support at least when compiling PHP). The description of the author in it is also very detailed and you can get anything you need to know.
Recently, I also saw an article about PHP output buffering. It says that PHP4.0.4 has introduced a new way of processing output buffers--ob_gzhandler, which works the same as the classes described above, but the difference is that you simply 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 specific reason, if you do not want to set up here, only where needed to change the default settings (not compressed), as long as the need to compress the PHP source directory, modify the. htaccess file, use the following syntax:
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 bring additional overhead to the server. I highly recommend that you use this method. The change can be explained by the following example, if the customer is using a 28.8K modem, after this process, he will think suddenly replaced by an ISDN access. One thing to note: Netscape Communicator does not support image compression, so it will not be displayed. So unless your customers are all using Internet Explorer, you must suppress the compression of JPEG and GIF images. The compression of other files should be fine, but I suggest you better test it, especially if the browser uses an uncommon plugin or a less-than-human browser.
Other useful things ...
Zend Technologies's Online store opened 24 this January and sells some interesting products related to PHP. Including the aforementioned Zend Cache,zend Encoder (in short, a compiler for PHP code that can generate compiled classes so that you can sell to customers without worrying about leaking source code.) On Web servers that need to run these classes, the Zend Encoder runtime will be used to decode them), Zend Ide (an integrated development environment for PHP with a lot of 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 be aware of the following points:
1. Bottlenecks may not be in PHP, you need to look at each object in the app (such as a database)
2. The performance of a Web server is limited, so do not think that bad performance is the cause of PHP, it may be a large number of visits, your server needs to upgrade, or consider using a load-balanced system (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 good performance, but to consider the use of slow modem users.
http://www.bkjia.com/PHPjc/315820.html www.bkjia.com true http://www.bkjia.com/PHPjc/315820.html techarticle one of the advantages of PHP is that it is fast and is sufficient for general website applications. However, if the site traffic is high, with narrow or other factors to make the server generated ...
