Analyse des paquets de réponse Apache gzippés

Question

Après avoir activé la compression gzip sur mon serveur Apache (mod_deflate), j'ai constaté de façon constante que les utilisateurs finaux étaient servis en moyenne 200 ms plus lentement que les réponses non compressées.

Comme c'était inattendu, j'ai modifié la directive de compression afin de compresser UNIQUEMENT les réponses texte / HTML, j'ai déclenché une connexion par fils et regardé le vidage réseau avant et après la compression.

Voici mes observations sur un GET avec un trafic minimal sur le réseau

Avant la compression

 
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)

Après la compression

 
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)

Une fois la compression définie, il est clair et compréhensible que le nombre de transactions sur le réseau est nettement inférieur au nombre de transactions non compressées.

Cependant, le transfert de l’unité de données comprimée a pris beaucoup plus de temps de la source à la destination.

Il semble que le travail supplémentaire de compression prenne du temps, mais on ne comprend pas pourquoi chaque donnée envoyée était beaucoup plus lente lorsqu’elle est comprimée.

Selon ma compréhension du processus de compression,

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

Avec ce schéma, je supposerais que la 3ème étape est (l’étape avant le tout premier segment de la réponse prendrait plus de temps car nous sommes - en train de compresser + en répondant - mais le reste des morceaux que je supposais devoir prendre en moyenne le même temps que les morceaux non compressés, mais ils ne le sont pas.

Quelqu'un peut-il me dire pourquoi ... ou suggérer un meilleur moyen d'analyser ce scénario? Aussi, est-ce que quelqu'un a une comparaison avant et après ... J'apprécierais vos commentaires / commentaires / questions

Answer 1

J'utilisais un test insuffisant pour comparer les deux scénarios (je pense moins de 100 ressources). Avec des tests suffisants - plus de 6 000 URL, cela a montré que le temps de réponse compressé au premier octet était plus rapide de 200 millisecondes, alors que TTLB était plus rapide de 25 millisecondes en moyenne.

Je n'ai pas testé ce que je prévois de faire et met à jour cette réponse.