18 de Enero, 2006

¿Compresión transparente con PHP o vía mod_gzip?

Tampoco es una comparativa rigurosa, ni pretendo que lo sea, solo un par de pruebas que quizás me permitan sacar alguna conclusión.

¿Por qué es importante servir las páginas comprimidas? No siempre lo es, pero en este caso se trata de un servidor casero, con un ancho de banda muy limitado (150 Kbps, que además se usan para muchas cosas :P), y los problemas que podría suponer el coste de CPU para la máquina por comprimir los contenidos on the fly no llegan a darse (porque antes me quedo sin ancho de banda).

Así que merece la pena ahorrar un 66% aproximadamente de espacio en cada página web que se sirve. No todo se comprime, desde luego (en las imágenes no habría beneficio), pero estoy convencido de que compensa poder enviar tres páginas en el espacio de una.

Ahora, debido a unos problemas que tuve con mod_gzip en OpenBSD 3.8 (aparentemente solucionados), empecé a usar la compresión transparente de PHP en su lugar. Bueno, ¿qué es mejor?

La compresión de PHP solo afecta a las páginas servidas desde ese lenguaje, mientras que mod_gzip es capaz de comprimir cualquier contenido. Dejando ese punto de lado, y sin tener en cuenta consumos de recursos, voy a emplear el Apache benchmarking tool para ver cómo responden los dos contra la portada de este blog. Simplemente: a ver quién es más rápido.

Como he hecho en otras pruebas, voy a realizar 10 peticiones concurrentes durante 10 segundos:

$  ab -H "Accept-Encoding: gzip" -c 10 -t 10 -w http://blackshell.usebox.net/

Resultados con compresión PHP

...
       Document Length:     8536 bytes
      Concurrency Level:    10
    Time taken for tests:   0.10022 seconds
      Complete requests:    62
       Failed requests:     0
      Total transferred:    574224 bytes
      HTML transferred:     557768 bytes
     Requests per second:   6.19
...

Resultados con mod_gzip

...
       Document Length:     8402 bytes
      Concurrency Level:    10
    Time taken for tests:   0.10045 seconds
      Complete requests:    61
       Failed requests:     0
      Total transferred:    538492 bytes
      HTML transferred:     522112 bytes
     Requests per second:   6.07
...

He repetido la prueba varias veces y el resultado no varía lo suficiente en cuanto a velocidad: son equivalentes. Aunque hay que descatar, en este caso como ejemplo, los 34 KB menos que se transmiten con mod_gzip.

Claro que no he medido qué cantidad de recursos consume cada una de las opciones, así que esta prueba no ha sido muy concluyente, pese a que mod_gzip parece algo más eficiente (en ambos he usado opciones por defecto, ajustando configuraciones no sé qué se podría conseguir).

A falta de más datos nos tendríamos que conformar con los pros y los contras obvios: mod_gzip es más versátil y nos permitirá comprimir cualquier contenido, y la compresión vía PHP está muy bien si servimos principalmente páginas que funcionan con ese lenguaje y no queremos (podemos) instalar un módulo más especializado en el servidor.

Anotación por Juan J. Martínez.

Hay 2 comentarios

Gravatar

Como se suele decir en estos casos... a ver si me animo. Me da pereza pasar a STABLE, aunque si es la única forma de hacer funcionar mod_gzip, habrá que hacer un esfuerzo.

¿Has probado ab para intentar colapsar Apache alguna vez?. Tiene que ser interesante saber el límite de peticiones que puede aguantar :).

por r0sk, en 2006-01-18 11:42:38

Gravatar

Hombre, hay que trabajar con STABLE... o al menos aplicar los parches serios a la versión del sistema que se instala (osea, o 3.8-release + parches o 3.8-stable, que viene a ser lo mismo).

A veces pasa... recuerdo que en la 3.3 había un problema con la librería pthreads que hacía petar a MySQL, y eso solo se solucionaba si pasabas a STABLE el sistema (no hubo parche).

Ojo que puedes llevar el kernel a STABLE y el sistema no, o el sistema solo y no el kernel. Pero vamos, que ya lo comenté hace tiempo qué era cada cosa :)

por Juanjo, en 2006-01-18 13:05:21

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.