SoFunction
Updated on 2025-04-09

Full guide to improve PHP execution speed (Part 2)

After the above two methods, I believe that the performance of your PHP application has been greatly improved. Now it is time to consider it from another aspect: download speed. If your application is just running within the company, all customers use 100Mb/s Ethernet to connect to the server, this may not be a problem, but if your customers use slow modem connections, you should consider using content compression.
According to IETF specifications, most browsers support gzip's internal
Contains compression. This means that before sending the web content to the client's browser, you can use gzip to compress it first. The browser will automatically decompress the data when it receives it and let 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(/columns/) that compresses static web pages. It works great, you just need 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, etc. But I tried it, and it doesn't seem to work. I learned in the mailing list of mod_gzip that this bug will be fixed in the next version (I think it should be version 1.3.14.6f). But you can still use it as compression of static content.

However, we also want to compress dynamic content, so we must find another way. One way is to use (/code/), just call this PHP class at the beginning and end of your PHP script to compress your page content. If the entire site requires such compression, you can call these functions in auto_prepend and auto_append in your file. It works well, but it obviously brings a little overhead on heavy load sites. To learn more about how it works, take a look at its class code (you need to at least add zlib support when compiling PHP). The author's explanations in it are 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 output buffering method - ob_gzhandler. Its function is the same as the class introduced above, but the difference is that you just need to use the following syntax in yours:

output_handler = ob_gzhandler ;

This will activate PHP's output buffering function and compress everything it sends. For some special reasons, if you don't want to set it here, only change this default setting where you need it (not compressed). Just modify the .htaccess file in the PHP source code directory that needs to be compressed. The syntax used is 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 method is good and does not incur additional system overhead for the server. I highly recommend that you use this method. Its change can be illustrated by the following example. If the customer is using a 28.8K modem, after this processing, he will think that it suddenly changed to an ISDN access. One thing to note is that Netscape Communicator does not support image compression, so it will not be displayed. So unless your customers all use Internet Explorer, you must disable compressing jpeg and gif images. There should be no problem with compressing other files, but I suggest you better test it, especially if the browser uses unusual plug-ins or browsers that are rarely used by people.

Other useful things...

Zend Technologies' online store was launched on January 24 this year and sells some interesting products related to PHP. Including the aforementioned Zend Cache, Zend Encoder (simply put, it is a PHP code compiler that can produce compiled classes so that you can sell them to customers without worrying about leaking source code. On web servers that need to run these classes, you will use Zend Encoder Runtime to decode them), Zend Ide (an integrated development environment for PHP with a lot of powerful performance), and support services provided for PHP developers.

in conclusion

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

1. The bottleneck may not be in PHP, you need to examine every object in the application (such as the database)

2. The performance of a web server is limited, so don’t think that poor performance is the reason for PHP. It may also be because of the large number of visits. Your server needs to be upgraded, or consider using a load balancing system (it will cost a lot of money)

3. Don’t think that content compression is not important. In a 100Mb/s LAN, your PHP application may perform well, but consider users who use slow modem.