Unterschied zwischen globalem maxconn und Server maxconn haproxy

Willy hat mir eine Antwort per Email geschickt. Ich dachte, ich würde es teilen. Seine Antworten sind fett gedruckt.

Ich habe eine Frage zu meiner Haproxy-Konfiguration:

   #---------------------------------------------------------------------
   # 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

Wie Sie sehen, ist es einfach, aber ich bin ein bisschen verwirrt darüber, wie die Eigenschaften von maxconn funktionieren.

Es gibt die globale und die maxconn auf dem Server im Listen-Block.

nd es gibt auch einen anderen im Listen-Block, der standardmäßig 2000 ist.

Meiner Meinung nach verwaltet der globale Server die Gesamtzahl der Verbindungen, die Haproxy als Dienst auf einmal verwaltet oder verarbeitet.

Richtig. Dies ist die maximale Anzahl gleichzeitiger Verbindungen pro Prozess.

Wenn die Zahl darüber liegt, bricht sie entweder die Verbindung ab oder bündelt sie in einem Linux-Socket?

In letzterem Fall werden einfach keine neuen Verbindungen mehr akzeptiert und sie verbleiben in der Socket - Warteschlange im Kernel. Die Anzahl der Sockets in der Warteschlange wird durch die min Listen Block ist maxconn).

Ich habe keine Ahnung, was passiert, wenn die Zahl höher als 4000 wird.

Die überschüssigen Verbindungen warten, bis eine andere abgeschlossen ist, bevor sie akzeptiert werden. Solange jedoch die Warteschlange des Kernels nicht voll ist, bemerkt der Client dies nicht einmal, da die Verbindung am TCP level wird aber nicht verarbeitet, so dass der Client nur eine gewisse Verzögerung bei der Verarbeitung der Anfrage feststellt. In der Praxis ist jedoch der maxconn-Wert des Listen-Blocks viel wichtiger, da er standardmäßig kleiner als der globale ist. Der maxconn-Wert des Listen begrenzt den Anzahl der Verbindungen pro Listener Im Allgemeinen ist es ratsam, ihn für die Anzahl der Verbindungen zu konfigurieren, die Sie für den Dienst benötigen, und den globalen Wert für maxconn auf die maximale Anzahl von Verbindungen festzulegen, die der Haproxy-Prozess verarbeiten kann. beide können auf den gleichen Wert gesetzt werden. Wenn Sie jedoch über viele Dienste verfügen, können Sie leicht verstehen, dass dies einen großen Unterschied macht, da Sie nicht möchten, dass ein einziger Dienst alle Verbindungen übernimmt und verhindert, dass die anderen funktionieren. =

Dann haben Sie die Eigenschaft server maxconn auf 15 gesetzt. Zunächst einmal habe ich diese auf 15 gesetzt, weil meine PHP-Fpm, die auf einem separaten Server weitergeleitet wird, nur so viele untergeordnete Prozesse hat, die sie verwenden kann, und deshalb stelle ich sicher, dass ich es bin bündelt die Anfragen hier anstatt in php-fpm. Was ich denke ist schneller.

Ja, es sollte nicht nur schneller sein, sondern es ermöglicht Haproxy, wann immer möglich, einen anderen verfügbaren Server zu finden, und es ermöglicht es auch, die Anforderung in der Warteschlange zu beenden, wenn der Client auf "Stop" klickt, bevor die Verbindung weitergeleitet wird der Server.

Aber zurück zum Thema, meine Theorie zu dieser Nummer ist, dass jedem Server in diesem Block nur 15 Verbindungen gleichzeitig gesendet werden. Und dann warten die Verbindungen auf einen offenen Server. Wenn ich Cookies aktiviert hätte, würden die Verbindungen auf den offenen CORRECT-Server warten. Ich aber nicht.

Das ist genau das Prinzip. Es gibt eine Proxy-Warteschlange und eine Server-Warteschlange. Verbindungen mit einem Persistenz-Cookie werden in die Server-Warteschlange und andere Verbindungen in die Proxy-Warteschlange gestellt. Da in Ihrem Fall jedoch kein Cookie vorhanden ist konfiguriert sind, gehen alle Verbindungen in die Proxy-Warteschlange. Sie können das Diagramm doc/queuing.fig in Haproxy-Quellen einsehen, wenn Sie möchten, es erklärt, wie/wo Entscheidungen getroffen werden.

Fragen sind also:

1. Was passiert, wenn die globalen Verbindungen über 4000 werden? Sterben sie? Oder irgendwie unter Linux bündeln?

   Sie befinden sich unter Linux in der Warteschlange. Sobald Sie die Warteschlange des Kernels überfüllt haben, werden sie im Kernel abgelegt.

2. Hat die globale Verbindung etwas mit den Serververbindungen zu tun, außer dass Sie nicht mehr Serververbindungen als global haben können?

   Nein, globale und Serververbindungseinstellungen sind unabhängig.

3. Sollte es sich beim Ermitteln der globalen Verbindungen nicht um die Anzahl der Verbindungen im Serverbereich zuzüglich eines bestimmten Prozentsatzes für das Pooling handeln? Und natürlich haben Sie andere Einschränkungen bei den Verbindungen, aber wie viele möchten Sie wirklich an die Proxys senden?

   Sie haben es richtig verstanden. Wenn die Antwortzeit Ihres Servers kurz ist, kann es nicht schaden, Tausende von Verbindungen in die Warteschlange zu stellen, um nur wenige gleichzeitig zu bedienen, da dies die Verarbeitungszeit für Anforderungen erheblich verkürzt. Heutzutage wird praktisch eine Verbindung hergestellt In einem Gigabit-LAN ​​dauert es ungefähr 5 Mikrosekunden. Daher ist es sehr sinnvoll, dass Haproxy die Verbindungen so schnell wie möglich aus der Warteschlange auf einen Server mit einer sehr kleinen maxconn verteilt Läuft mit einer Warteschlange von 30 pro Server! Es war ein Apache-Server, und Apache ist mit einer geringen Anzahl von Verbindungen viel schneller als mit einer großen Anzahl. Aber dafür brauchen Sie wirklich einen schnellen Server, weil Sie nicht alles haben wollen Clients in der Warteschlange warten auf einen Verbindungssteckplatz, weil der Server beispielsweise auf eine Datenbank wartet. Wenn Ihre Site viele statische Daten enthält, können Sie die statischen Anforderungen an weiterleiten einen Pool von Servern (oder Caches), damit Sie keine statischen Anforderungen in die Warteschlange stellen und die statischen Anforderungen keine teuren Verbindungssteckplätze belegen. Hoffentlich hilft das, Willy