Willy hat mir eine Antwort per E-Mail 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 unkompliziert, aber ich bin etwas verwirrt darüber, wie die maxconn-Eigenschaften funktionieren.
Es gibt die globale und die maximale Verbindung auf dem Server im Listen-Block.
Und es gibt noch einen anderen im Listen-Block, der standardmäßig so etwas wie 2000 ist.
Mein Gedanke ist folgender: Der globale verwaltet die Gesamtzahl der Verbindungen, die Haproxy als Dienst gleichzeitig in die Warteschlange stellt oder verarbeitet.
Richtig. Dies ist die maximale Anzahl gleichzeitiger Verbindungen pro Prozess.
Wenn die Zahl darüber hinausgeht, wird entweder die Verbindung unterbrochen oder in einem Linux-Socket zusammengefasst?
Je später, es werden einfach keine neuen Verbindungen mehr akzeptiert und diese verbleiben in der Socket-Warteschlange im Kernel. Die Anzahl der Suiten in der Warteschlange wird durch das Minimum von (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog und das maxconn des Listenblocks) bestimmt.
Ich habe keine Ahnung, was passiert, wenn die Zahl höher als 4000 wird.
Die überschüssigen Verbindungen warten, bis eine weitere abgeschlossen ist, bevor sie akzeptiert werden. Solange die Warteschlange des Kernels jedoch nicht gesättigt ist, bemerkt der Client dies nicht einmal, da die Verbindung auf TCP-Ebene akzeptiert, aber nicht verarbeitet wird. Der Client bemerkt also nur eine Verzögerung bei der Bearbeitung der Anfrage. In der Praxis ist das maxconn des Listenblocks jedoch viel wichtiger, da es standardmäßig kleiner als das globale ist. Das maxconn des Listen begrenzt die Anzahl der Verbindungen pro Listener. Im Allgemeinen ist es ratsam, es für die Anzahl der Verbindungen zu konfigurieren, die Sie für den Dienst wünschen, und das globale maxconn für die maximale Anzahl von Verbindungen zu konfigurieren, die der Haproxy-Prozess verarbeiten lässt. Wenn Sie nur einen Dienst haben, können beide auf den gleichen Wert eingestellt werden. Aber wenn Sie viele Dienste haben,
Dann haben Sie die Server-Maxconn-Eigenschaft auf 15 gesetzt. Zunächst einmal habe ich diese auf 15 gesetzt, da meine PHP-Fpm, die auf einem separaten Server weitergeleitet wird, nur so viele untergeordnete Prozesse hat, die sie verwenden kann, also stelle ich sicher, dass ich es bin Pooling der 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 ihm auch, die Anforderung in der Warteschlange zu beenden, wenn der Client auf "Stopp" klickt, bevor die Verbindung an den Server weitergeleitet wird.
Aber zurück zum Thema, meine Theorie über diese 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 RICHTIGEN offenen Server warten. Aber ich nicht.
Das ist genau das Prinzip. Es gibt eine Proxy-Warteschlange und eine Server-Warteschlange. Verbindungen mit einem Persistenz-Cookie werden in die Serverwarteschlange und andere Verbindungen in die Proxy-Warteschlange gestellt. Da in Ihrem Fall jedoch kein Cookie konfiguriert ist, werden alle Verbindungen in die Proxy-Warteschlange gestellt. Wenn Sie möchten, können Sie sich das Diagramm doc / queuing.fig in Haproxy-Quellen ansehen. Dort wird erläutert, wie / wo Entscheidungen getroffen werden.
Fragen sind also:
Was passiert, wenn die globalen Verbindungen über 4000 liegen? Sterben sie Oder irgendwie unter Linux bündeln?
Sie stehen unter Linux in der Warteschlange. Sobald Sie die Warteschlange des Kernels überfordert haben, werden sie im Kernel abgelegt.
Bezieht sich die globale Verbindung auf die Serververbindungen, abgesehen von der Tatsache, dass Sie nicht eine größere Anzahl von Serververbindungen als global haben können?
Nein, globale und Serververbindungseinstellungen sind unabhängig.
Sollte es bei der Ermittlung der globalen Verbindungen nicht die Anzahl der im Serverabschnitt hinzugefügten Verbindungen plus ein bestimmter Prozentsatz für das Pooling sein? Und natürlich haben Sie andere Einschränkungen bei den Verbindungen, aber wirklich, wie viele möchten Sie an die Proxies senden?
Du hast es richtig. Wenn die Antwortzeit Ihres Servers kurz ist, ist es nichts Falsches, Tausende von Verbindungen in die Warteschlange zu stellen, um jeweils nur wenige zu bedienen, da dies die Verarbeitungszeit für Anforderungen erheblich verkürzt. Praktisch dauert das Herstellen einer Verbindung heutzutage in einem Gigabit-LAN etwa 5 Mikrosekunden. Es ist daher sehr sinnvoll, haproxy die Verbindungen so schnell wie möglich von seiner Warteschlange auf einen Server mit einem sehr kleinen maxconn verteilen zu lassen. Ich erinnere mich, dass eine Spieleseite mehr als 30000 gleichzeitige Verbindungen in die Warteschlange stellte und mit einer Warteschlange von 30 pro Server lief! Es war ein Apache-Server, und Apache ist mit einer kleinen Anzahl von Verbindungen viel schneller als mit einer großen Anzahl. Aber dafür brauchst du wirklich einen schnellen Server, weil du nicht ' Sie möchten nicht, dass alle Ihre Clients in der Warteschlange auf einen Verbindungssteckplatz warten, da der Server beispielsweise auf eine Datenbank wartet. Was auch sehr gut funktioniert, ist das Widmen von Servern. Wenn Ihre Site über viele statische Daten verfügt, können Sie die statischen Anforderungen an einen Pool von Servern (oder Caches) weiterleiten, damit Sie keine statischen Anforderungen in die Warteschlange stellen und die statischen Anforderungen keine teuren Verbindungssteckplätze verschlingen. Ich hoffe, das hilft, Willy