Was ist Socket-Segmentierung im Nginx-Server?

Mit der Version 1.9.1 von Nginx wird eine neue Funktion eingeführt: Sie ermöglicht die Verwendung der Socket-Option so_reuseport, die in neuen Versionen vieler Betriebssysteme verfügbar ist, einschließlich Dragonfly BSD und Linux (Kernel-Version 3.9 und höher). Mit dieser Socket-Option können mehrere Sockets dieselbe IP- und Port-Kombination überwachen. Der Kernel ist in der Lage, die Last eingehender Verbindungen über diese Sockets zu verteilen. (Für Nginx Plus-Kunden wird diese Funktion in Version 7 erscheinen, die Ende des Jahres veröffentlicht wird)

Die Option so_reuseport bietet viele potenzielle reale Anwendungen. Andere Dienste können es auch nutzen, um fortlaufende Upgrades einfach während der Ausführung umzusetzen (nginx unterstützt bereits fortlaufende Upgrades). Für Nginx kann die Aktivierung dieser Option in bestimmten Szenarien Sperrenkonflikte reduzieren und die Leistung verbessern.

Wie in der Abbildung unten beschrieben, benachrichtigt ein separater Listening-Socket den Worker-Prozess über die Verbindung, auf die zugegriffen wird, und jeder Worker-Thread versucht, die Verbindung herzustellen, wenn die Option so_reuseport gültig ist.

Wenn die Option so_reuseport aktiviert ist, gibt es mehrere Socket-Listener für jede IP-Adresse und portgebundene Verbindung, und jedem Arbeitsprozess kann einer zugewiesen werden. Der Systemkernel bestimmt, welcher gültige Socket-Listener (und implizit für welchen Arbeitsprozess) die Verbindung erhält. Dies kann die Sperrenkonkurrenz zwischen Arbeitsprozessen beim Erhalten neuer Verbindungen verringern (Anmerkung des Übersetzers: Konkurrenz zwischen Arbeitsprozessen, die sich gegenseitig ausschließende Ressourcensperren anfordern) und die Leistung auf Mehrkernsystemen verbessern. Dies bedeutet jedoch auch, dass, wenn ein Arbeitsprozess in einen Blockierungsvorgang gerät, die Blockierung nicht nur den Arbeitsprozess betrifft, der die Verbindung akzeptiert hat, sondern auch dazu führt, dass der Arbeitsprozess, der vom Kernel geplant ist, die Verbindungsanforderung sendet und daher wird blockiert.

Gemeinsam genutzten Socket einrichten

Damit die Socket-Option so_reuseport funktioniert, sollte der neue Reuseport-Parameter direkt für das Listenelement in der Kommunikationsoption http oder tcp (Stream-Modus) eingeführt werden, z folgendes Beispiel:

Code kopieren Der Code lautet wie folgt:

http {
Server { listen 80 reuseport;
server_name localhost; ...
}
}

stream {
server { listen 12345 reuseport;
                                                                           ​

Nach dem Verweisen auf den Reuseport-Parameter ist der Accept_mutex-Parameter für den referenzierten Socket ungültig, da der Mutex (Mutex) für Reuseport redundant ist. Für Ports, die Reuseport nicht verwenden, ist es dennoch sinnvoll, Accept_mutex festzulegen.

Reuseports Benchmark-Leistungstest

Ich habe das Benchmark-Tool auf einer 36-Kern-AWS-Instanz ausgeführt, um 4 Nginx-Worker-Prozesse zu testen. Um die Auswirkungen des Netzwerks zu reduzieren, werden sowohl der Client als auch Nginx lokal ausgeführt und Nginx zurückgeben lassen ok String statt einer Datei. Ich habe drei Nginx-Konfigurationen verglichen: Standard (entspricht „accept_mutex on“), „accept_mutex off“ und „reuseport“. Wie in der Abbildung dargestellt, sind die Anforderungen pro Sekunde beim Reuseport zwei- bis dreimal so hoch wie bei den anderen, während auch die Latenz und die Standardabweichung der Latenz verringert werden.

Ich habe einen weiteren entsprechenden Leistungstest durchgeführt – der Client und Nginx befanden sich auf unterschiedlichen Maschinen und Nginx gab eine HTML-Datei zurück. Wie in der folgenden Tabelle gezeigt, ähnelt die Latenzreduzierung mithilfe von Reuseport dem vorherigen Leistungstest, wobei die Standardabweichungsreduzierung der Latenz signifikanter ist (fast ein Zehntel). Andere Ergebnisse (nicht in der Tabelle aufgeführt) sind gleichermaßen ermutigend. Mithilfe von Reuseport wird die Last gleichmäßig auf die Worker-Prozesse verteilt. Unter Standardbedingungen (entspricht „accept_mutex“ aktiviert) erhalten einige Worker einen höheren Prozentsatz der Last, während bei deaktiviertem „accept_mutex“ alle Worker eine höhere Last erhalten.

Code kopieren Der Code lautet wie folgt:

Latenz (ms) Latenz Standarddev (ms) CPU-Last

Standard 15,65 26,59 0,3

accept_mutex aus 15,59 26,48 10

Wiederverwendung 12,35 3,15 0,3

In diesen Leistungstests wird die Geschwindigkeit der Verbindungsanforderung gemessen ist sehr hoch, aber die Anfrage erfordert keinen großen Verarbeitungsaufwand. Andere grundlegende Tests sollten darauf hinweisen, dass Reuseport auch die Leistung erheblich verbessern kann, wenn der Anwendungsverkehr in dieses Szenario passt. (Der Reuseport-Parameter kann nicht in der Listen-Direktive im E-Mail-Kontext, z. B. E-Mail, verwendet werden, da der E-Mail-Verkehr diesem Szenario definitiv nicht entspricht.) Wir empfehlen Ihnen, ihn zunächst zu testen, anstatt ihn direkt in großem Umfang anzuwenden.

Das obige ist der detaillierte Inhalt vonWas ist Socket-Segmentierung im Nginx-Server?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!