Des problèmes avec la compression HTTP?

Question

Nous étudions actuellement l'utilisation de la compression HTTP sur une application fournie par JBoss. Après avoir modifié les paramètres du Tomcat SAR, nous constatons une compression d’environ 80% - c’est évidemment formidable, mais je tiens à rester prudent… avant d’implémenter ce système dans son ensemble, quelqu'un a-t-il rencontré des problèmes d'utilisation de la compression HTTP?

Quelques points à noter pour ma situation.

• Nous avons un contrôle total sur le navigateur - toute la société utilise donc IE6 / 7
• L'application est interne uniquement
• Lors des tests de charge, la charge de notre serveur d'applications était relativement faible: la base de données était notre goulot d'étranglement
• Nous avons le contrôle sur les ordinateurs clients et ils reçoivent tous une vérification des spécifications (processeur correct / 2 Go de RAM)

Toute expérience dans ce domaine serait très appréciée!

Answer 1

Tant que vous respectez correctement l'en-tête Accept-Encoding du client (c.-à-d. ne fournissez pas de fichiers compressés aux clients qui ne peuvent pas les décompresser), vous ne devriez pas avoir de problème.

Oh, et rappelez-vous que le déflater est plus rapide que gzip .

Answer 2

La compression n’est pas considérée comme exotique ni comme un avantage sanglant et (fwiw) je n’en ai jamais entendu parler, ni rencontré de problème.

Answer 3

Une compression à la volée peut augmenter la charge du processeur sur le serveur. Si possible, pré-compresser les ressources statiques et mettre en cache les réponses dynamiques compressées peuvent combattre cela.

Answer 4

C’est une très bonne idée. Cela ajoutera une légère charge CPU à votre serveur, mais ce n'est généralement pas votre goulot d'étranglement. Cela accélérera le chargement de vos pages et vous utiliserez moins de bande passante.