análisis de paquete de respuesta Apache comprimido

Question

Después de habilitar la compresión gzip en mi servidor Apache (mod_deflate), encontré consistentemente que el usuario final estaba siendo atendido en promedio 200 ms más lento que las respuestas sin comprimir.

Esto fue inesperado, así que modifiqué la directiva de compresión para comprimir SOLAMENTE las respuestas de texto / HTML, activé wirehark y miré el volcado de red antes y después de la compresión.

Aquí están mis observaciones de un GET con tráfico mínimo en la red

Antes de la compresión

 
Transactions on the wire: 46

Total time for 46 trans: 791ms
  i. TCP seq/ack:       14ms
 ii. 1st data segment: 693ms 
iii. Remaining:         83ms (27/28 data units transferred + tcp/ip handshakes)

Después de la compresión

 
Transactions on the wire: 10

Total time for 46 trans: 926ms
  i. TCP seq/ack:       14ms
 ii. 1st data segment: 746ms 
iii. Remaining:        165ms  (5 out of 6 data units transfered)

Después de establecer la compresión, es claro y comprensible que el número de transacciones en el cable es significativamente menor que sin comprimir.

Sin embargo, la unidad de datos comprimidos tardó mucho más tiempo en transferirse del origen al destino.

Parece que el trabajo adicional de compresión lleva tiempo comprensiblemente, pero no puede entender por qué cada información enviada fue significativamente más lenta cuando se comprimió.

Mi comprensión del proceso de compresión es:

  1. GET Request is received by Apache
  2. Apache identifies resource
  3. Compress the resource
  4. Respond with compressed response

Con este esquema, supondría que el tercer paso es (el paso anterior al primer segmento de la respuesta tomaría más tiempo ya que estamos - comprimiendo + respondiendo - pero el resto de los fragmentos que supuse deberían tomar en promedio el mismo tiempo que los fragmentos sin comprimir, pero no lo son.

¿Alguien puede decirme por qué ... o sugerir una mejor manera de analizar este escenario? Además, ¿alguien tiene una comparación de antes y después ... Agradecería cualquier comentario / comentario / pregunta

Answer 1

Estaba usando pruebas insuficientes para comparar los dos escenarios (creo que menos de 100 recursos). Con suficientes pruebas, más de 6000 urls, demostró que el tiempo de respuesta comprimido al primer byte fue más rápido en 200 milisegundos al servir texto / html, mientras que TTLB fue más rápido en 25 milisegundos en promedio.

No he probado esto, lo cual planeo hacer y actualizar esta respuesta.