Willy m'a fait une réponse par e-mail. J'ai pensé que je voudrais partager. Ses réponses sont en gras.
J'ai une question au sujet de mon haproxy config:
#---------------------------------------------------------------------
# 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 assez simple, mais je suis un peu confus sur la façon dont le
maxconn travail de propriétés.
Il est le mondial et le maxconn sur le serveur, dans le bloc listen.
Et il y a aussi un autre dans le bloc listen, qui est par défaut à quelque chose
comme 2000.
Ma pensée est: est-ce que le programme mondial gère le nombre total de connexions
que haproxy, comme un service, au québec ou d'un processus à la fois.
Correct. C'est le nombre maximum de connexions simultanées.
Si le nombre
obtient ci-dessus, il tue la connexion, des bassins ou dans certains linux
socket?
Plus tard, il s'arrête tout simplement d'accepter de nouvelles connexions et ils restent dans la
prise de file d'attente dans le noyau. Le nombre de queuable sockets est déterminé
par le min de (net.de base.somaxconn, net.ipv4.tcp_max_syn_backlog et de la
écouter du bloc maxconn).
Je n'ai aucune idée de ce qui se passe si le nombre devient supérieur à 4000.
L'excès de connexions attendre pour un autre, pour terminer, avant d'être
accepté. Toutefois, tant que le noyau de la file d'attente n'est pas saturé, la
le client n'a pas le même avis, ceci, tant que la connexion est acceptée à l'
Au niveau TCP, mais n'est pas traitée. Ainsi, le client seulement des avis un peu de retard
pour traiter la demande.
Mais dans la pratique, l'écoute de l'édifice de l'maxconn est beaucoup plus important,
car par défaut il est plus petit qu'à l'échelle mondiale. L'écoute du maxconn
limite le nombre de connexions par l'auditeur. En général, il est sage de
configurer le nombre de connexions que vous souhaitez pour le service,
et pour configurer le mondial maxconn pour le nombre max de connexions
vous laissez le haproxy handle de processus. Lorsque vous avez un seul service,
les deux peuvent être réglés à la même valeur. Mais lorsque vous avez de nombreux services,
vous pouvez facilement comprendre qu'il fait une énorme différence, que vous n'avez pas
voulez un service unique de prendre toutes les connexions et de prévenir la
autres de travailler.
Ensuite, vous avez le serveur maxconn bien fixé à 15. Tout d'abord, j'ai mis que à
15 parce que mon php-fpm, c'est de transférer sur un serveur distinct seulement a
donc, de nombreux enfants au processus qu'il peut utiliser, j'ai donc assurez-vous que je suis en commun de la demande
ici, au lieu de php-fpm. Je pense que c'est plus rapide.
Oui, non seulement il devrait être plus rapide, mais il permet de haproxy pour trouver un autre
serveur disponible chaque fois que possible, et cela permet aussi de tuer l'
demande dans la file d'attente si le client hits "stop" avant que la connexion est
transmis au serveur.
Mais pour en revenir sur le sujet, ma théorie à propos de ce nombre est chaque serveur dans ce
bloc ne sera envoyée 15 connexions à la fois. Et puis les connexions
va attendre un serveur ouvert. Si j'avais des cookies sur, les connexions attendre
pour le bon serveur ouvert. Mais je n'ai pas.
C'est exactement le principe. Il y a une par de procurations de la file d'attente et par serveur
la file d'attente. Les connexions avec une persistance de cookie allez sur le serveur de file d'attente et
d'autres connexions vont à la procuration de la file d'attente. Cependant, puisque dans votre cas, pas de
cookie est configuré, toutes les connexions passent à la procuration de la file d'attente. Vous pouvez regarder
dans le schéma de la doc et de file d'attente.fig dans haproxy sources si vous le souhaitez, il explique
comment/où sont prises les décisions.
Donc les questions sont:
- Ce qui se passe si les connexions mondiales obtenir au-dessus de 4000? - Ils mourir? Ou
piscine dans Linux en quelque sorte?
Ils sont mis en file d'attente dans linux. Une fois que vous submerger le noyau de la file d'attente, alors qu'ils sont
tombé dans le noyau.
- Mondial de connexion liés à l'connexions au serveur, autres que
le fait que vous ne pouvez pas avoir un nombre total de connexions au serveur de plus de
global?
Non, global et les paramètres de connexion au serveur sont indépendantes.
- Pour déterminer les liens à l'échelle mondiale, ne devrait-elle pas être le montant de
connexions ajoutées dans la section serveur, en plus d'un certain pourcentage pour
mise en commun? Et, évidemment, vous avez d'autres liens sur les connexions, mais
c'est vraiment combien vous voulez envoyer le proxy?
Vous l'avez droit. Si votre serveur le temps de réponse est court, il n'y a rien
de mal avec la mise en queue des milliers de connexions à ne servir que quelques-uns à la fois,
parce qu'il réduit considérablement le traitement de la demande de temps. Pratiquement,
l'établissement d'une connexion de nos jours prend environ 5 microsecondes sur un gigabit
LAN. Donc, il fait beaucoup de sens pour laisser haproxy distribuer les connexions
aussi rapide que possible de la file d'attente sur un serveur avec une très petite maxconn.
Je me souviens d'un site de jeux de files d'attente de plus de 30000 connexions simultanées
et en cours d'exécution avec une file d'attente de 30 par serveur ! C'était un serveur apache, et
apache est beaucoup plus rapide avec de petits nombres de connexions avec les grandes
les numéros. Mais pour cela, vous avez vraiment besoin d'un serveur rapide, car vous n'avez pas
voulez avoir tous vos clients en file d'attente pour une connexion fente, car
le serveur est en attente d'une base de données par exemple.
Aussi quelque chose qui fonctionne très bien est de dédier des serveurs. Si votre site
a beaucoup de la statique, vous pouvez diriger les requêtes statiques à un pool de serveurs
(ou les caches), de sorte que vous n'avez pas de file d'attente des requêtes statiques sur eux, et que le
des requêtes statiques ne mangent pas cher baies de connexion.
En espérant que cela aide,
Willy
