Problemas con la compresión HTTP?

Question

Estamos investigando el uso de la compresión HTTP en una aplicación que JBoss está sirviendo. Después de realizar el cambio de configuración en el SAR de Tomcat, estamos viendo una compresión de aproximadamente el 80%. Obviamente, esto es genial. Sin embargo, quiero ser cauteloso ... antes de implementar todo este sistema, ¿alguien ha encontrado problemas al utilizar la compresión HTTP?

Un par de puntos a tener en cuenta para mi situación.

• Tenemos control total sobre el navegador, por lo que toda la compañía utiliza IE6 / 7
• La aplicación es interna solamente
• Durante las pruebas de carga, nuestro servidor de aplicaciones tenía una carga relativamente pequeña: la base de datos era nuestro cuello de botella
• Tenemos control sobre las máquinas cliente y todos obtienen una verificación de especificaciones (procesador decente / 2GB de RAM)

¡Cualquier experiencia con esto sería muy apreciada!

Answer 1

Mientras respete correctamente el encabezado Accept-Encoding del cliente (es decir, no sirva archivos comprimidos a clientes que no puedan descomprimirlos), no debería tener ningún problema.

Ah, y recuerda que deflate es más rápido que gzip .

Answer 2

La compresión no se considera exótica o de vanguardia y (fwiw) No he oído hablar de ningún problema con ella.

Answer 3

La compresión sobre la marcha puede aumentar la carga de la CPU en el servidor. Si es posible, los recursos estáticos de precompresión y el almacenamiento en caché de las respuestas dinámicas comprimidas pueden combatir eso.

Answer 4

Es solo una muy buena idea en todos los sentidos. Agregará una pequeña carga de CPU a su servidor, pero generalmente no es su cuello de botella. Hará que sus páginas se carguen más rápido y usará menos ancho de banda.