Différence entre global maxconn et serveur maxconn haproxy
J'ai une question à propos de 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 constater, le processus 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. Ma pensée est la suivante: le global gère le nombre total de connexions qu’haproxy, en tant que service, met en file d'attente ou traite en même temps. Si le nombre dépasse cette valeur, la connexion est coupée ou des pools sont installés dans un socket Linux? Je n'ai aucune idée de ce qui se passe si le nombre dépasse 4000.
Ensuite, vous avez la propriété server maxconn définie sur 15. Premièrement, je l'ai définie sur 15 car mon php-fpm, il s'agit d'une transmission sur un serveur séparé, ne dispose que de tant de processus enfants qu'il peut utiliser. regrouper les demandes ici, au lieu de dans php-fpm. Ce que je pense est plus rapide.
Mais revenons sur le sujet, ma théorie à propos de ce nombre est que chaque serveur de ce bloc ne recevra que 15 connexions à la fois. Et puis les connexions attendront un serveur ouvert. Si j'avais des cookies, les connexions attendraient le serveur ouvert CORRECT. Mais je ne.
Donc, les questions sont:
- Que se passe-t-il si les connexions globales dépassent 4000? Meurent-ils? Ou pool dans Linux en quelque sorte?
- La connexion globale est-elle liée aux connexions de serveur, mis à part le fait que vous ne pouvez pas avoir un nombre total de connexions de serveur supérieur à global?
- Lors de la détermination des connexions globales, ne devrait-il pas être le nombre de connexions ajoutées dans la section serveur, plus un certain pourcentage pour la mise en commun? Et évidemment, vous avez d'autres contraintes sur les connexions, mais en réalité, c'est combien vous voulez envoyer aux mandataires?
Merci d'avance.
Willy m'a reçu une réponse par email. Je pensais que je le partagerais. Ses réponses sont en gras.
J'ai une question à propos de 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 constater, le processus 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 a aussi un autre dans le bloc d'écoute qui vaut par défaut 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 ou traite en même temps.
Correct. C'est le nombre maximum de connexions simultanées par processus.
Si le nombre dépasse cette valeur, la connexion est coupée ou des pools sont installés dans un socket Linux?
Le dernier, il cesse tout simplement d’accepter de nouvelles connexions et elles restent dans la file d’attente du noyau. Le nombre de sockets en file d'attente est déterminé par le min de (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog et écoutez le maxconn du bloc).
Je n'ai aucune idée de ce qui se passe si le nombre dépasse 4000.
Les connexions excédentaires attendent la fin d'une autre connexion avant d'être acceptées. Toutefois, 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. Donc, le client ne remarque qu'un peu de retard dans le traitement de la demande, mais dans la pratique, le maxconn du bloc d'écoute est beaucoup plus important car, par défaut, il est plus petit que le global, ce qui limite le nombre de connexions par auditeur. En général, il est judicieux de le configurer pour le nombre de connexions souhaitées pour le service et de configurer le maxconn global sur le nombre maximal de connexions que le processus haproxy gère. Lorsque vous ne disposez que d’un service, vous pouvez définir les deux même valeur. Mais lorsque vous avez plusieurs services, vous pouvez facilement comprendre que cela fait une différence énorme, car vous ne voulez pas qu'un seul service prenne toutes les connexions et empêche les autres de fonctionner.
Ensuite, vous avez la propriété server maxconn définie sur 15. Premièrement, je l'ai définie sur 15 car mon php-fpm, il s'agit d'une transmission sur un serveur séparé, ne dispose que de tant de processus enfants qu'il peut utiliser. regrouper les demandes ici, au lieu de dans php-fpm. Ce que je pense est plus rapide.
Oui, non seulement cela devrait être plus rapide, mais cela permet également à haproxy de trouver un autre serveur disponible dans la mesure du possible, ainsi que de tuer la demande dans la file d'attente si le client clique sur "stop" avant que la connexion ne soit transférée. le serveur.
Mais revenons sur le sujet, ma théorie à propos de ce nombre est que chaque serveur de ce bloc ne recevra que 15 connexions à la fois. Et puis les connexions attendront un serveur ouvert. Si j'avais des cookies, les connexions attendraient le serveur ouvert CORRECT. Mais je ne.
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 à la file d'attente du proxy. Cependant, dans votre cas, aucun cookie n'est Lorsque toutes les connexions sont configurées, 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.
Donc, les questions sont:
Que se passe-t-il si les connexions globales dépassent 4000? Meurent-ils? Ou pool dans Linux en quelque sorte?
Ils sont mis en file d'attente sous Linux. Une fois que vous avez surchargé la file d'attente du noyau, ils sont alors déposés dans le noyau.
La connexion globale est-elle liée aux connexions de serveur, mis à part le fait que vous ne pouvez pas avoir un nombre total de connexions de serveur supérieur à global?
Non, les paramètres de connexion globaux et du serveur sont indépendants.
Lors de la détermination des connexions globales, ne devrait-il pas être le nombre de connexions ajoutées dans la section serveur, plus un certain pourcentage pour la mise en commun? Et évidemment, vous avez d'autres contraintes sur les connexions, mais en réalité, c'est combien vous voulez envoyer aux mandataires?
Vous avez tout compris. Si le temps de réponse de votre serveur est court, la mise en file d'attente de milliers de connexions pour ne servir que quelques-unes ne pose aucun problème, car elle réduit considérablement le temps de traitement des demandes. Pratiquement, établir une connexion de nos jours Cela prend environ 5 microsecondes sur un réseau local gigabit. Il est donc logique de laisser haproxy répartir les connexions aussi rapidement que possible de sa file d’attente à un serveur avec un très petit maxconn. Il s’agissait d’un serveur Apache, et Apache est beaucoup plus rapide avec un petit nombre de connexions que avec un grand nombre. Mais pour cela, vous avez vraiment besoin d’un serveur rapide, car vous ne voulez pas des clients en attente d'un emplacement de connexion car le serveur attend une base de données, par exemple. Ce qui fonctionne également très bien consiste à dédier des serveurs. Si votre site comporte de nombreuses statiques, vous pouvez diriger les demandes statiques vers un pool de serveurs (ou caches) afin que vous ne mettiez pas en file d'attente les demandes statiques et que les demandes statiques ne consomment pas de slots de connexion coûteux. En espérant que cela aide, Willy