Impact de Connection Close vs Keep-alive

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
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.

— Shane Madden

Ma formulation était peut-être un peu étrange, mais le serveur envoie évidemment les en-têtes. J'essaie de savoir quel impact cela aura sur le client et le serveur.

— Willemk

Quel type d'équilibreur de charge avez-vous si dysfonctionnel qu'il casse HTTP Keepalive?

— voretaq7

Nous avons une règle qui envoie un sous-dossier à différentes batteries de serveurs. Lorsque vous naviguez de la racine vers le sous-dossier, Keep-alive maintient la connexion ouverte à la batterie de serveurs d'origine et ne vous envoie pas à la batterie de serveurs prévue.

— Willemk

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.

— Shane Madden
source

Je viens de vérifier, il y a environ 3 à 6 (selon la page sur laquelle vous êtes) des objets en cours de chargement à partir de ce domaine. Cela me fait penser que le ralentissement sera minime, car il aurait ouvert ~ 6 connexions simultanées de toute façon.

— Willemk

@Willemk Oui, c'est très minime pour une page typique - le ralentissement serait beaucoup plus préoccupant sur une page chargeant des dizaines d'objets. Ça devrait être bien.

— Shane Madden

CDN prend la majeure partie de la charge.

— Willemk

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.

— Mircea Vutcovici
source

Vous pouvez rencontrer des problèmes d'authentification si vous utilisez l'authentification NTLM et que les connexions persistantes sont désactivées.

— Mircea Vutcovici

J'essaie de quantifier "grandement améliorer". De plus, notre équipe informatique est en pourparlers avec le fournisseur d'équilibrage de charge sur le problème.

— Willemk