Est-ce que le fait d'avoir un équilibreur de charge vous permet de réutiliser les connexions de socket ?

Je suppose que vous faites référence à SO_REUSEADDR plutôt qu'au multiplexage de connexion. Le seul avantage que cela donne est qu'une prise dans l'état TIME_WAIT n'empêche pas une nouvelle prise de se lier à la même adresse. Je n'ai jamais rencontré un système qui utilise réellement la phase TIME_WAIT pour ce qu'elle est censée faire - si vous avez beaucoup de prises en TIME_WAIT, peut-être devriez-vous simplement réduire le délai d'attente.

Le fait d'accélérer le processus aiderait également - mais vous n'avez pas donné beaucoup d'informations sur la configuration ici et le schéma de trafic.

N'importe quel type de répartiteur de charge de proxy vous donnera encore moins de connexions clients que vous n'avez actuellement (car chaque connexion entrante nécessite une connexion aux périphériques en aval). D'autre part, le RRDNS divisera la charge sans la complexité et le coût d'un point unique de défaillance.

c'est une seule requête POST

Nous parlons donc d'HTTP ici? Si c'est le cas, alors il y a un ÉNORME potentiel d'optimisation.

Tous les principaux répartiteurs de charge ont une forme de réutilisation et de regroupement de connexions, ils l'appellent simplement différemment. Ils sont en fin de compte conçus pour traiter les paquets très rapidement et efficacement.

F5 l'appelle OneConnect, Netscaler TCP multiplexing… Je ne sais pas suffisamment sur les autres fournisseurs ou solutions open-source.

Cette fonctionnalité permet aux répartiteurs de charge de réutiliser les connexions TCP du côté serveur et améliore considérablement les performances de l'application web sur le back-end. Lorsqu'une connexion est terminée en quelque sorte, elle est déplacée dans un pool de réutilisation sur le répartiteur de charge et appariée à une connexion ultérieure si elle est adaptée (si elle n'est pas adaptée, le répartiteur de charge ouvrira une nouvelle connexion TCP vers le serveur). Il n'y a pas de fermeture de connexion et donc pas besoin des poignées de main à trois voies sur les nouvelles connexions ou pour le serveur d'assigner ou de supprimer la mémoire assignée aux sockets ouverts. L'autre chose à noter est que les connexions côté serveur sont séquentielles, ce n'est pas du pipelining.

Sans réutilisation de connexion, il y a une corrélation 1-1 (entre le client et le serveur) et selon mon expérience, les performances (de l'application) sont nettement réduites avec une charge plus élevée sur le serveur en back-end. Si c'est du trafic SSL, vous verrez une charge CPU en raison des échanges de clés.

Je pense que cela dépendra de l'équilibreur de charge. Je sais que F5 a une fonction appelée OneConnect qui permet à l'équilibreur de charge de multiplexer plusieurs requêtes vers des sockets ouverts. Cela réduit les frais généraux de création/destruction de socket pour chaque transaction de protocole de niveau supérieur.

Je sais que d'autres équilibreurs de charge ont des fonctionnalités similaires, bien que je ne les connaisse pas aussi bien.