Willy m'a répondu par e-mail. J'ai pensé que je le partagerais. Ses réponses sont en gras.
J'ai une question sur ma configuration haproxy:
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
log 127.0.0.1 syslog emerg
maxconn 4000
quiet
user haproxy
group haproxy
daemon
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode http
log global
option abortonclose
option dontlognull
option httpclose
option httplog
option forwardfor
option redispatch
timeout connect 10000 # default 10 second time out if a backend is not found
timeout client 300000 # 5 min timeout for client
timeout server 300000 # 5 min timeout for server
stats enable
listen http_proxy localhost:81
balance roundrobin
option httpchk GET /empty.html
server server1 myip:80 maxconn 15 check inter 10000
server server2 myip:80 maxconn 15 check inter 10000
Comme vous pouvez le voir, c'est simple, mais je suis un peu confus quant au fonctionnement des propriétés maxconn.
Il y a le global et le maxconn sur le serveur, dans le bloc d'écoute.
Et il y en a aussi un autre dans le bloc d'écoute qui par défaut est quelque chose comme 2000.
Ma pensée est la suivante: le global gère le nombre total de connexions que haproxy, en tant que service, va que ou traiter en même temps.
Correct. Il s'agit du nombre maximal de connexions simultanées par processus.
Si le nombre dépasse cela, cela tue la connexion ou des pools dans une socket Linux?
Le plus tard, il arrête simplement d'accepter de nouvelles connexions et elles restent dans la file d'attente de socket dans le noyau. Le nombre de sockets en file d'attente est déterminé par le minimum de (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog et le maxconn du bloc d'écoute).
Je n'ai aucune idée de ce qui se passe si le nombre dépasse 4000.
Les connexions en excès attendent qu'une autre se termine avant d'être acceptées. Cependant, tant que la file d'attente du noyau n'est pas saturée, le client ne le remarque même pas, car la connexion est acceptée au niveau TCP mais n'est pas traitée. Ainsi, le client ne remarque qu'un délai pour traiter la demande. Mais en pratique, le maxconn du bloc d'écoute est beaucoup plus important, car par défaut, il est plus petit que le bloc global. Le maxconn de l'écoute limite le nombre de connexions par auditeur. En général, il est sage de le configurer pour le nombre de connexions que vous souhaitez pour le service, et de configurer le maxconn global au nombre maximum de connexions que vous laissez le processus haproxy gérer. Lorsque vous n'avez qu'un seul service, les deux peuvent être définis sur la même valeur. Mais lorsque vous avez de nombreux services,
Ensuite, vous avez la propriété maxconn du serveur définie à 15. Tout d'abord, je la mets à 15 car mon php-fpm, il est transféré sur un serveur séparé, n'a qu'un nombre limité de processus enfants qu'il peut utiliser, donc je m'assure que je suis regrouper les requêtes ici, au lieu de php-fpm. Ce qui, je pense, est plus rapide.
Oui, non seulement cela devrait être plus rapide, mais cela permet à haproxy de trouver un autre serveur disponible chaque fois que possible, et aussi il lui permet de tuer la requête dans la file d'attente si le client frappe "stop" avant que la connexion ne soit transmise au serveur.
Mais revenons sur le sujet, ma théorie sur ce nombre est que chaque serveur de ce bloc ne sera envoyé que 15 connexions à la fois. Et puis les connexions attendront un serveur ouvert. Si j'avais des cookies, les connexions attendraient le bon serveur ouvert. Mais moi non.
C'est exactement le principe. Il existe une file d'attente par proxy et une file d'attente par serveur. Les connexions avec un cookie de persistance vont à la file d'attente du serveur et les autres connexions vont à la file d'attente du proxy. Cependant, puisque dans votre cas aucun cookie n'est configuré, toutes les connexions vont à la file d'attente du proxy. Vous pouvez consulter le diagramme doc / queuing.fig dans les sources haproxy si vous le souhaitez, il explique comment / où les décisions sont prises.
Les questions sont donc:
Que se passe-t-il si les connexions globales dépassent 4000? Est-ce qu'ils meurent? Ou pool sous Linux en quelque sorte?
Ils sont mis en file d'attente sous Linux. Une fois que vous avez submergé la file d'attente du noyau, ils sont déposés dans le noyau.
La connexion globale est-elle liée aux connexions serveur, à part le fait que vous ne pouvez pas avoir un nombre total de connexions serveur supérieur à global?
Non, les paramètres de connexion globale et serveur sont indépendants.
Lors de la détermination des connexions globales, ne devrait-il pas s'agir du nombre de connexions ajoutées dans la section serveur, plus un certain pourcentage pour la mise en commun? Et évidemment, vous avez d'autres restrictions sur les connexions, mais c'est vraiment combien vous voulez envoyer aux mandataires?
Vous avez bien compris. Si le temps de réponse de votre serveur est court, il n'y a rien de mal à mettre en file d'attente des milliers de connexions pour n'en servir que quelques-unes à la fois, car cela réduit considérablement le temps de traitement des demandes. En pratique, l'établissement d'une connexion prend aujourd'hui environ 5 microsecondes sur un LAN gigabit. Il est donc très logique de laisser haproxy distribuer les connexions aussi rapidement que possible de sa file d'attente vers un serveur avec un très petit maxconn. Je me souviens d'un site de jeu mettant en file d'attente plus de 30000 connexions simultanées et fonctionnant avec une file d'attente de 30 par serveur! C'était un serveur Apache, et Apache est beaucoup plus rapide avec un petit nombre de connexions qu'avec un grand nombre. Mais pour cela, vous avez vraiment besoin d'un serveur rapide, car vous ne le faites pas t voulez que tous vos clients soient mis en file d'attente pour un slot de connexion car le serveur attend une base de données par exemple. Un autre élément qui fonctionne très bien est de dédier des serveurs. Si votre site a beaucoup de statiques, vous pouvez diriger les demandes statiques vers un pool de serveurs (ou caches) afin de ne pas mettre en file d'attente des demandes statiques sur eux et que les demandes statiques ne mangent pas d'emplacements de connexion coûteux. En espérant que cela aide, Willy