Nehmen wir den pragmatischen Ansatz.
All diese Grenzen sind Dinge, die im vergangenen Jahrhundert, als Hardware langsam und teuer war, fest programmiert und entworfen wurden. Wir sind jetzt im Jahr 2016, ein durchschnittlicher Wall-Mart-Toaster kann mehr Anfragen als die Standardwerte verarbeiten.
Die Standardeinstellungen sind tatsächlich gefährlich. Hunderte von Benutzern auf einer Website zu haben, ist nichts Beeindruckendes.
worker_process
Eine verwandte Einstellung, lassen Sie es uns erklären, während wir uns mit dem Thema befassen.
Nginx als Load Balancer:
- 1 Worker für den HTTP-Lastenausgleich.
- 1 Worker pro Core für den HTTPS-Lastenausgleich.
Nginx als Webserver:
Dieser ist schwierig.
Einige Anwendungen / Frameworks / Middleware (z. B. php-fpm) werden außerhalb von Nginx ausgeführt. In diesem Fall ist 1 Nginx-Worker ausreichend, da in der Regel die externe Anwendung die umfangreiche Verarbeitung und den Ressourcenverbrauch übernimmt.
Einige Anwendungen / Frameworks / Middleware können jeweils nur eine Anforderung verarbeiten, und es kommt zu einem Fehlschlag, wenn sie überlastet werden.
Im Allgemeinen ist ein Arbeiter immer eine sichere Wette.
Andernfalls können Sie einen Arbeiter pro Kern einsetzen, wenn Sie wissen, was Sie tun. Ich würde diesen Weg als eine Optimierung betrachten und ein richtiges Benchmarking und Testen empfehlen.
worker_connections
Die Gesamtzahl der Verbindungen beträgt worker_process * worker_connections. Die Hälfte im Lastausgleichsmodus.
Jetzt erreichen wir den Toasterteil. Es gibt viele stark unterschätzte Systemgrenzen:
- ulimits ist 1k max offene Dateien pro Prozess unter Linux (1k soft, 4k hard bei einigen Distributionen)
- systemd limits entspricht in etwa ulimits.
- Nginx Standard ist 512 Verbindungen pro Worker.
- Es könnte mehr geben: SELinux, sysctl, supervisord (jede Distribution + Version ist etwas anders)
1k worker_connections
Die sichere Voreinstellung ist, überall 1k zu setzen.
Es ist hoch genug, um mehr als die meisten internen und unbekannten Websites jemals zu sein. Es ist niedrig genug, um keine anderen Systemgrenzen zu überschreiten.
10k worker_connections
Es ist sehr verbreitet, Tausende von Kunden zu haben, insbesondere für eine öffentliche Website. Ich habe aufgehört, die Anzahl der Websites zu zählen, die aufgrund der geringen Standardeinstellungen gesunken sind.
Das für die Produktion akzeptable Minimum beträgt 10.000. Zugehörige Systemgrenzen müssen erhöht werden, um dies zu ermöglichen.
Es gibt kein zu hohes Limit (ein Limit hat einfach keine Wirkung, wenn es keine Benutzer gibt). Ein zu niedriges Limit ist jedoch eine sehr reale Sache, die abgelehnte Benutzer und eine tote Site zur Folge hat.
Mehr als 10k
10k ist schön und einfach.
Wir könnten ein willkürliches Limit von 1000kk setzen (es ist immerhin nur ein Limit), aber das ergibt praktisch keinen Sinn, wir bekommen diesen Traffic nie und können es trotzdem nicht aushalten.
Bleiben wir bei 10k als vernünftige Einstellung. Die Dienste, die mehr wollen (und können), erfordern ein spezielles Tuning und Benchmarking.
Spezialszenario: Erweiterte Verwendung
Manchmal wissen wir, dass der Server nicht über viele Ressourcen verfügt, und wir erwarten Spitzen, gegen die wir nicht viel tun können. Wir lehnen Benutzer lieber ab, als es zu versuchen. Legen Sie in diesem Fall ein angemessenes Verbindungslimit fest und konfigurieren Sie nützliche Fehlermeldungen und Vorgehensweisen.
Manchmal funktionieren die Back-End-Server gut und gut, aber nur bis zu einer gewissen Auslastung , und alles geht schnell nach Süden. Wir möchten lieber langsamer fahren, als dass die Server abstürzen. Konfigurieren Sie in diesem Fall die Warteschlangen mit strengen Grenzwerten, und lassen Sie Nginx die gesamte Wärme puffern, während die Anforderungen in einem begrenzten Tempo ausgeführt werden.