Comprimir contenido con PHP ob_start() vs Apache Deflate/Gzip?

Question

La mayoría de los sitios quieren comprimir su contenido para ahorrar ancho de banda. Sin embargo, cuando se trata de servidores apache que ejecutan PHP, existen dos formas de hacerlo: with PHP o apache. Entonces, ¿cuál es más rápido o más fácil en su servidor?

Por ejemplo, en PHP funciono con la siguiente función en el inicio de mis páginas que les permitan:

/** 
* 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'); 
    } 

} 

El other option es utilizar Apache deflate or gzip (tanto las que están very close). Para habilitarlos, puede agregar algo como esto a su archivo .htaccess.

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

Desde PHP es un lenguaje de script (que debe ser cargado por PHP) yo asumiría que el método Apache sería 1) más estable y 2) más rápido. Pero las suposiciones no tienen mucho uso en el mundo real.

Después de todo, supondrías que con las enormes ventanas de respaldo financiero tiene ... uh, no iremos.

Answer 1

Estamos ejecutando ... una gran cantidad de servidores web, manejando 60M/uniques/día. Normalmente esto no vale la pena mencionar, pero su pregunta parece basada en la experiencia.

Corremos con hacerlo en apache. Lo que sale por el otro extremo es el mismo (o lo suficientemente cerca como para no importar), independientemente del método que elija.

Elegimos Apache para algunas razones:

• Cero mantenimiento, que sólo lo encendió. Nadie necesita mantener alguna estructura de caso
• Rendimiento, en nuestros servidores de pruebas donde Apache hizo el trabajo marginalmente mejor.
• Apache aplicará el filtro de salida a todo, en lugar de solo PHP. En algunas ocasiones hay otros tipos de contenido que se sirven en el mismo servidor, nos gustaría para comprimir nuestra .css y .js

Una palabra de advertencia, algunos navegadores u otras aplicaciones a propósito mangle las cabeceras de los clientes que indican esa compresión es compatible. Algunos lo hacen para facilitar su trabajo en términos de seguridad del lado del cliente (piense en aplicaciones como la seguridad en Internet norton y tal). Puede ignorar esto o intentar agregar casos adicionales para volver a escribir las solicitudes para que se vean normales (los navegadores sí lo admiten, la aplicación o el proxy simplemente lo han simplificado para facilitar su propia vida).

Alternativamente, si está utilizando el comando flush() para enviar resultados al navegador anteriormente, y está aplicando compresión, puede necesitar rellenar el final de la cadena con espacios en blanco para convencer al servidor de enviar datos con anticipación .