Je configure nos serveurs et, en raison de la nature de notre équilibreur de charge, nous ne pouvons pas envoyer d'en-têtes de connexion persistants. J'essaie de déterminer l'impact de l'envoi de ces en-têtes à la fois à l'utilisateur final et au serveur. Soit on remarque quelque chose?
connection
http-headers
keepalive
Willemk
la source
la source
sending these headers to both the end-user and the server- Hein? Pouvez-vous être plus précis sur ce que vous cherchez à faire? D'où les en-têtes seraient-ils envoyés et comment cela fonctionnerait-il autour de la limitation de votre équilibreur de charge contre les connexions HTTP persistantes? Travailler en continu a besoin de plus qu'un simple en-tête, il a besoin de la coopération de chaque appareil impliqué dans les aspects HTTP de la connexion.Réponses:
D'abord et avant tout, criez. Bruyamment. Chez votre fournisseur. Pour avoir un produit ne prenant pas en charge le protocole HTTP / 1.1 vieux de plus d'une décennie .
L'impact de l'absence de connexions persistantes augmente considérablement le temps de chargement des ressources. Avec keep-alive, une seule connexion TCP peut être utilisée pour demander plusieurs ressources; sans, une nouvelle session TCP (avec une nouvelle négociation à trois voies - et, si vous utilisez SSL, une nouvelle négociation SSL) est requise pour chaque ressource de la page.
En termes pratiques, l'impact dépendra du nombre de ressources sur une page, du temps d'aller-retour entre le client et le serveur, et du nombre de demandes simultanées qu'un navigateur client fait à la fois (les navigateurs modernes exécutent ~ 6ish par défaut) . Beaucoup de ressources par page et des clients distants signifieront une augmentation très sensible des temps de chargement des pages.
la source
Garder en vie améliorera considérablement les performances côté client et côté serveur. Si possible, ne le désactivez pas. L'équilibreur de charge devrait fonctionner correctement avec la fonction keep alive activée.
la source