¿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.
Hay 2 comentarios
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 :)
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.
por r0sk, en 2006-01-18 11:42:38 ∞