Préface

J'ai réglé HAProxy depuis un certain temps et j'ai effectué de nombreux tests de performances dessus. De 100 requêtes HTTP/s à 50 000 requêtes HTTP/s.

Le premier conseil est de activer la page de statistiques sur HAProxy. Vous AVEZ besoin de surveiller, pas d'exception. Vous devrez également peaufiner si vous prévoyez de dépasser les 10 000 requêtes/s.

Les délais d'expiration sont une bête confuse car ils ont une grande gamme de valeurs possibles, la plupart d'entre elles n'ayant aucune différence observable. Je n'ai encore rien vu échouer en raison d'un nombre 5% inférieur ou supérieur. 10000 vs 11000 millisecondes, qui s'en soucie? Probablement pas votre système.

Configuration

Je ne peux pas en toute conscience donner quelques chiffres comme 'meilleurs délais d'attente jamais pour tout le monde'.

Je peux plutôt dire quels sont les délais d'attente LES plus agressifs qui sont toujours acceptables pour l'équilibrage de charge HTTP(S). Si vous rencontrez des chiffres inférieurs à ceux-ci, il est temps de reconfigurer votre équilibreur de charge.

timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000

délai client:

Le délai d'inactivité s'applique lorsque le client est censé accuser réception ou envoyer des données. En mode HTTP, ce délai est particulièrement important à considérer pendant la première phase, lorsque le client envoie la requête, et pendant le réponse lorsqu'il lit les données envoyées par le serveur.

Lire: Ceci est le temps maximum pour recevoir les en-têtes de la requête HTTP du client.

Les connexions 3G/4G/56k/satellite peuvent parfois être lentes. Pourtant, elles devraient être capables d'envoyer les en-têtes HTTP en quelques secondes, PAS en 30.

Si quelqu'un a une connexion si mauvaise qu'il a besoin de plus de 30s pour demander une page (puis plus de 10*30s pour demander les 10 images embarquées/CSS/Javascript), je pense qu'il est acceptable de le rejeter.

délai serveur:

Le délai d'inactivité s'applique lorsque le serveur est censé accuser réception ou envoyer des données. En mode HTTP, ce délai est particulièrement important à considérer pendant la première phase de réponse du serveur, lorsqu'il doit envoyer les en-têtes, car il représente directement le temps de traitement du serveur pour la demande. Pour déterminer quelle valeur y placer, il est souvent bon de commencer par ce qui serait considéré comme des temps de réponse inacceptables, puis de vérifier les journaux pour observer la distribution des temps de réponse, et ajuster la valeur en conséquence.

Lire: Ceci est le temps maximum pour recevoir les en-têtes de réponse HTTP du serveur (après avoir reçu la requête complète du client). Fondamentalement, c'est le temps de traitement de vos serveurs avant de commencer à envoyer la réponse.

Si votre serveur est tellement lent qu'il nécessite plus de 30s pour commencer à donner une réponse, alors je pense qu'il est acceptable de le considérer comme mort.

Cas particulier: Certains services RARES effectuant un traitement très lourd peuvent mettre une minute entière ou plus pour répondre. Ce délai peut nécessiter d'être considérablement augmenté pour cette utilisation spécifique. (Remarque : Il s'agit probablement d'une mauvaise conception, utilisez une communication de style asynchrone ou ne utilisez pas HTTP du tout.)

délai de connexion:

Définir le temps maximum à attendre pour qu'une tentative de connexion à un serveur réussisse.

Lire: Le temps maximum qu'un serveur a pour accepter une connexion TCP.

Les serveurs sont dans le même LAN que HAProxy, donc cela devrait être rapide. Donnez-lui au moins 5 secondes car c'est le temps que cela peut prendre en cas d'événement imprévu (une perte de paquet TCP à retransmettre, un serveur créant un nouveau processus pour prendre les nouvelles demandes, un pic de trafic).

Cas particulier: Lorsque les serveurs sont dans un LAN différent ou sur une liaison peu fiable. Ce délai peut devoir être considérablement augmenté. (Remarque : Il s'agit probablement d'une mauvaise architecture.)

délai de vérification:

Définir un délai de vérification supplémentaire, mais seulement après qu'une connexion a déjà été établie.

Définir un délai de vérification supplémentaire, mais seulement après qu'une connexion a déjà été établie. Si défini, haproxy utilise le minimum entre "délai de connexion" et "inter" comme délai de connexion pour la vérification et "délai de vérification" comme un délai de lecture supplémentaire. Le "minimum" est utilisé pour que les personnes utilisant un "délai de connexion" très long (par ex. ceux qui en avaient besoin en raison de la file d'attente ou du tarpit) ne ralentissent pas leurs vérifications. (Veuillez également noter qu'il n'y a aucune raison valable d'avoir des délais de connexion aussi longs, car "délai de file d'attente" et "délai de tarpit" peuvent toujours être utilisés pour éviter cela).

Lire: Lors de l'exécution d'un test de santé, le serveur a délai de connexion pour accepter la connexion puis délai de vérification pour donner la réponse.

Tous les serveurs DOIVENT avoir une vérification de santé HTTP(S) configurée. C'est la seule façon pour l'équilibreur de charge de savoir si un serveur est disponible. Le test de santé est une simple page /isalive répondant toujours OK.

Donnez ce délai d'au moins 5 secondes car c'est le temps que cela peut prendre en cas d'événement imprévu (une perte de paquet TCP à retransmettre, un serveur créant un nouveau processus pour prendre les nouvelles demandes, un pic de trafic).

Anecdote : Beaucoup de gens croient à tort que le serveur peut toujours répondre à cette page simple en 3 ms. Ils définissent un délai agressif (< 2000ms) avec un basculement agressif (2 échecs de vérification = serveur mort). J'ai vu des sites web entiers tomber à cause de cela. En général, il y a une légère augmentation du trafic, les serveurs backend deviennent plus lents, les vérifications de santé sont retardées... jusqu'à ce qu'elles expirment toutes ensemble, HAProxy pense que TOUS les serveurs sont morts en même temps et que le site entier tombe en panne.