13 de Diciembre, 2005

Alternativa a mod_gzip con PHP

Parece que mod_gzip está dando problemas en OpenBSD 3.8 por algunos cambios que se habrían hecho al API de zlib (sin confirmar no es eso, mod_gzip no usa zlib :P).

Resulta que Pedro quería ponerlo, y este tema nos ha tenido en jaque varios días hasta que hemos descubierto que quizás el fallo no sea culpa nuestra :D.

Mientras no conseguimos el tema de mod_gzip, hay una solución parcial: usar la compresión transparente de PHP (4.0.5 o superior, creo).

Se activa con zlib.output_compression = On, y ajustando un par de valores se pueden mejorar rendimientos. Como no tenemos tiempo para pruebas, nos fiamos de los valores por defecto por ahora.

Resultado:

$ wget -q -O gzip --header="Accept-Encoding: gzip" \
 http://www.maze.usebox.net/ && file gzip
gzip: gzip compressed data, from Unix
$ wget -q -O plano http://www.maze.usebox.net/ && file plano
plano: HTML document text
$ du -h plano gzip
36K     plano
12K     gzip

Desde luego queda lejos del rendimiento que da mod_gzip, que comprime todo menos lo que no deseemos comprimir (imágenes, por ejemplo), pero por ahora es más que suficiente para ahorrar un poco de ancho de banda si los contenidos que se sirven principalmente son páginas PHP.

El servidor de Pedro está, como este mismo, en una conexión residencial a Internet, con un ancho de banda de subida muy reducido. La compresión gzip de los contenidos permite servir aproximadamente 3 veces más con el mismo ancho de banda, compensando en mi opinión el gasto extra de CPU en el servidor y en el cliente.

Anotación por Juan J. Martínez, clasificada en: php.

Hay 4 comentarios

Gravatar

...mira tu por donde estaba pensando en migrar a 3.8 en casa (siempre después de comprar algo de memoria, porque actualmente 64Mb son insostenibles con un MySQL de por medio).

Buen truco, mi pregunta es la siguiente ¿funcionaría en conjunto con mod_gzip?. Es decir, uno es módulo de apache y otro una opción de PHP, con ambos activados ¿conseguiríamos mayor compresión?.

por r0sk, en 2005-12-14 09:31:33

Gravatar

Pues yo diría que no :D

Si mod_gzip lo comprimer todo, desactivaríamos la compresión en PHP.

por Juanjo, en 2005-12-14 10:00:39

Gravatar

No es oro todo lo que reluce, la gran desventaja de los sistemas de compresión en http es que muchos proxys no los soportan y determinados clientes ven el equivalente a realizar un cat del archivo comprimido.

Por otra parte, el 90% del ancho de banda consumido se va en imagenes y otros elementos que no se pueden comprimir por que ya llevan su propia compresión (claro ejemplo del jpeg), y el ratio es exageradamente bajo o nulo.

por aramosf, en 2005-12-15 09:41:39

Gravatar

Me refiero siempre al contenido que se comprime. Yo creo que sí hay beneficio. En el caso de Pedro pasaba de 36 a 12 KB, que ya es bastante. El texto de la web cargará más rápido, las fotos ya llegarán cuando puedan.

Claro, para un fotoblog (por ejemplo) tendría poca utilidad :). La tecnología está ahí, cada cual que la valore para su caso concreto.

por Juanjo, en 2005-12-15 11:37:17

Los comentarios están cerrados: los comentarios se cierran automáticamente una vez pasados 30 días. Si quieres comentar algo acerca de la anotación, puedes hacerlo por e-mail.

Algunas anotaciones relacionadas: