Compressing content with PHP ob_start() vs Apache Deflate/Gzip?

Question

Most sites want to compress their content to save on bandwidth. However, When it comes to apache servers running PHP there are two ways to do it - with PHP or with apache. So which one is faster or easier on your server?

For example, in PHP I run the following function at the start of my pages to enable it:

/**  * Gzip compress page output  * Original function came from wordpress.org  */ function gzip_compression() {      //If no encoding was given - then it must not be able to accept gzip pages     if( empty($_SERVER['HTTP_ACCEPT_ENCODING']) ) { return false; }      //If zlib is not ALREADY compressing the page - and ob_gzhandler is set     if (( ini_get('zlib.output_compression') == 'On'         OR ini_get('zlib.output_compression_level') > 0 )         OR ini_get('output_handler') == 'ob_gzhandler' ) {         return false;     }      //Else if zlib is loaded start the compression.     if ( extension_loaded( 'zlib' ) AND (strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== FALSE) ) {         ob_start('ob_gzhandler');     }  } 

The other option is to use Apache deflate or gzip (both which are very close). To enable them you can add something like this to your .htaccess file.

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/x-httpd-php 

Since PHP is a scripting language (which must be loaded by PHP) I would assume that the apache method would be 1) more stable and 2) faster. But assumptions don't have much use in the real world.

After all, you would assume that with the huge financial backing windows has... uh, we won't go there.

Answer 1

We're running... a lot of webservers, handling 60M/uniques/day. Normally this isn't worth mentioning but your question seems based on experience.

We run with doing it in apache. What comes out the other end is the same (or near enough so as to not to matter) regardless of the method you choose.

We choose apache for few reasons:

• Zero maintenance, we just turned it on. No one needs to maintain some case structure
• Performance, in our tests servers where Apache did the work faired marginally better.
• Apache will apply the output filter to everything, as opposed to just PHP. On some occasions there are other types of content being served on the same server, we'd like to compress our .css and .js

One word of warning, some browsers or other applications purposefully mangle the client headers indicating that compression is supported. Some do this to ease their job in terms of client side security (think applications like norton internet security and such). You can either ignore this, or try to add in extra cases to re-write requests to look normal (the browsers do support it, the application or proxy just futzed it to make its own life easier).

Alternatively, if you're using the flush() command to send output to the browser earlier, and you're applying compression you may need to pad the end of your string with whitespace to convince the server to send data early.