Différence entre haproxy global maxconn et serveur maxconn

91

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. Ma pensée est la suivante: le global gère le nombre total de connexions que haproxy, en tant que service, mettra en file d'attente ou traitera en même temps. Si le nombre dépasse cela, cela tue la connexion ou des pools dans une 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é 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.

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.

Les questions sont donc:

  1. Que se passe-t-il si les connexions globales dépassent 4000? Est-ce qu'ils meurent? Ou pool sous Linux en quelque sorte?
  2. 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?
  3. 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?

Merci d'avance.

chantheman
la source

Réponses:

166

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:

  1. 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.

  2. 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.

  3. 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

chantheman
la source
10
Merci d'avoir publié ceci.
Tarantula
9
J'ai un haproxy qui sert de proxy pour environ 200 autres backend. Une fois qu'un backend a été édité par DDOS avec environ ~ 300k connexions / seconde, tous les autres backend meurent. Avec la valeur maxconn 2048 sur le serveur backend (sous ddos), notre haproxy fonctionne bien. Merci beaucoup, vous m'avez sauvé une nuit :)
hungnv