compress - ¿Comprimiendo contenido con PHP ob_start() vs Apache Deflate/Gzip?

gzip compression laravel

Question

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

Por ejemplo, en PHP ejecuto la siguiente función al inicio de mis páginas para habilitarla:

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

}

La otra opción es usar Apache deflate o gzip (ambos están muy cerca ). Para habilitarlos puedes agregar algo como esto a tu archivo .htaccess.

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

Dado que PHP es un lenguaje de scripting (que debe ser cargado por PHP), asumiría que el método de 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ía que con las enormes ventanas de respaldo financiero tiene ... no iremos allí.

Answer 1

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

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

Elegimos apache por algunas razones:

• Cero mantenimiento, acabamos de encenderlo. Nadie necesita mantener alguna estructura de caso
• Rendimiento, en nuestros servidores de prueba donde Apache hizo el trabajo un poco mejor.
• Apache aplicará el filtro de salida a todo, y no solo a PHP. En algunas ocasiones hay otros tipos de contenido que se sirven en el mismo servidor, nos gustaría comprimir nuestros .css y .js

Una advertencia, algunos navegadores u otras aplicaciones modifican los encabezados de los clientes indicando que se admite la compresión. Algunos hacen esto para facilitar su trabajo en términos de seguridad del lado del cliente (piense en aplicaciones como Norton Internet Security y similares). Puede ignorar esto o intentar agregar casos adicionales para volver a escribir las solicitudes para que se vean normales (los navegadores lo admiten, la aplicación o el proxy lo han simplificado para hacer su propia vida más fácil).

Alternativamente, si está utilizando el comando flush () para enviar la salida al navegador antes, y está aplicando la compresión, es posible que deba rellenar el final de la cadena con espacios en blanco para convencer al servidor de que envíe los datos con anticipación.