Y a-t-il des suggestions sur quand dois-je utiliser roundrobinet quand dois-je utiliser leastconn?
J'utilise roundrobinactuellement et j'ai observé que le chargement de mon serveur principal n'est pas réparti également. Bien sûr, il peut y avoir un autre problème, mais nous voulons leastconnessayer, mais comme il s'agit d'un serveur essentiel à la mission, je veux consulter une autre expérience avant d'apporter les modifications.
Une idée à partager?
Je n'ai pas expérimenté avec lessconn, mais ma compréhension est que le cas d'utilisation typique de lessconn est lorsque vous équilibrez la charge de quelque chose qui peut avoir des connexions de longue durée. La raison en est que la moindre concentration se concentre sur la garantie d'une concurrence équilibrée alors que le tourniquet va fournir un taux d'arrivée plus équilibré . Si cette distinction n'est pas claire, voir ma réponse sur la différence .
Lorsque vous dites que la charge n'est pas répartie uniformément, cela pourrait aider à définir un peu mieux la «charge». Si vous voulez dire les ressources du serveur, je suggère d'identifier ce qui cause exactement l'augmentation de la charge (c'est-à-dire certains types de connexions) et de travailler en arrière à partir de là.
Cela dépend du protocole et du cas d'utilisation à équilibrer. Pour tout ce dont la quantité de connexions est corrélée à la charge / utilisation, il est préférable d'utiliser leastconn. En raison du fonctionnement des réseaux et des applications, c'est à peu près toujours vrai et il vaut mieux utiliser leastconnpar défaut.
Par exemple, une entreprise dispose d'un pool de bureaux distants auxquels les employés se connectent. Vous souhaitez que les employés soient répartis de manière assez uniforme sur les ordinateurs de bureau.
Le nombre de connexions actives dans ce cas d'utilisation est à peu près "combien d'employés utilisent ce bureau en ce moment". L'hôte ayant le moins de connexions utilise le moins d'employés et c'est probablement le moins chargé. Utilisez "lessconn" dans ces circonstances, cela répartit la charge uniformément avec le nombre d'utilisateurs.
Un équilibreur de charge idéal doit être conscient de la charge du bureau distant. Combien d'utilisateurs? Combien d'applications? Combien de mémoire et de CPU consommés? Il existe des solutions commerciales dédiées aux postes de travail distants (Microsoft / Citrix / etc ...), elles mesurent généralement ces métriques pour diffuser très bien l'utilisation. HAProxy est un simple équilibreur de charge réseau et il ne peut pas faire mieux que de compter les connexions avec leastconn.
Avec HTTP, une connexion active signifie que le serveur est occupé à traiter une demande. Les connexions sont directement proportionnelles à la charge. Vous souhaitez sélectionner le serveur avec le moins de connexions actives (requêtes en cours). À utiliser leastconnpour le trafic HTTP (S).
Imaginez un scénario avec deux serveurs HTTP, où un serveur est plus lent à traiter les demandes (peut-être qu'il est surchargé, peut-être qu'il a un matériel plus ancien).
roundrobinrépartira les demandes à moitié entre les deux serveurs. C'est très inefficace, le serveur le plus rapide devrait en prendre plus. Pire encore, le serveur plus lent pourrait être surchargé, il deviendrait encore plus lent à mesure que davantage de demandes arriveraient et pourrait commencer à supprimer des demandes à tout moment. Tu ne veux pas ça.
leastconndétecterait que les serveurs sont inégaux. Le serveur plus lent conserve les connexions plus longtemps, son nombre de connexions est plus élevé. leastconnen tient compte et préfère l'autre serveur.
D'après mon expérience, y compris les rôles où je faisais exclusivement des tests de performance pour les sites Web de taille moyenne à grande. leastconnpeut être 300% aussi efficace que roundrobinpour HTTP (S). roundrobinne distribue pas la connexion équitablement et entraînera une instabilité à forte charge.
(Ignorons que HAProxy ne prend pas en charge UDP et UDP est sans connexion).
Un dernier exemple. DNS est un protocole simple. Les clients envoient un seul message UDP pour demander un domaine et le serveur DNS répond dans un seul message.
Dans ce cas, il n'y a pas vraiment de connexion. Même s'il y en avait, il serait instantanément fermé (théoriquement).
Il ne serait pas logique de compter les connexions dans ces circonstances, ce n'est pas optimal pour leastconn. Un simple roundrobinpeut diffuser des messages.
Les gens pensent parfois qu'ils ne devraient pas utiliser leastconnpour des connexions de courte durée (similaire au dernier exemple). Même la documentation HAProxy est trompeuse à ce sujet.
leastconn
Use of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP.
[misleading advice, should ignore it]
Dans le monde réel, ce short connectionsn'est pas une chose.
Les applications sont construites sur TCP. Les messages sont livrés et souvent traités dans l'ordre. Lorsqu'un serveur est lent ou surchargé, les connexions "courtes" deviennent plus longues. S'il y a (plus) de connexions, il y a probablement (plus) de travail en cours. Le nombre de connexions et la durée de connexion varient et ont un sens.
Pensez à un serveur HTTP de base. Certains actifs prennent quelques millisecondes, certains appels d'API prennent quelques secondes, une page peut prendre n'importe quel temps pour se charger avec n'importe quelle quantité de demandes en elle, etc. Les demandes ne sont pas de courte durée, leur durée de vie suit ce qui est traité sur quel serveur. leastconncomprend l'activité en cours et ajuste la distribution, ce qui est exactement ce que vous attendez d'un équilibreur de charge.