Vorwort
Viele Senioren haben uns gewarnt, dass das Nachladen den reibungslosen Ablauf des gesamten Prozesses gewährleisten kann Eine vorzeitige Kündigung vor dem aktuellen Antrag ist nicht möglich. Viele Jahre lang habe ich diese Aussage nie in Frage gestellt, bis eines Tages beim Neuladen ein 502-Fehler auftrat und ich es noch einmal überdenken musste.
Wie lässt sich das Problem reproduzieren? Schreiben wir ein einfaches Skript zur Simulation:
<?php sleep(11); echo "foo"; ?>
Verwenden Sie zu diesem Zeitpunkt den Browser, um diese URL zu durchsuchen, und führen Sie dann sofort Folgendes aus Neuladevorgang. Sie können den Fehler 502 sehen.
Ist PHP so schwach? Kann ich nicht einmal garantieren, dass das Nachladen grundsätzlich reibungslos verläuft? Die Antwort ist natürlich nein, tatsächlich kann unser Ziel durch die
process_control_timeout
Parameter erreicht werden. Leider ist dieser Parameter standardmäßig auf 0 eingestellt, was bedeutet, dass er in diesem Artikel nicht auf 10 Sekunden festgelegt wird. Führen Sie die vorherigen experimentellen Schritte erneut aus. Diesmal werden die Ergebnisse normal ausgegeben. Wenn Sie jedoch noch ein paar Experimente durchführen, stellen Sie möglicherweise fest, dass der Schlaf sofort endet, wenn wir neu laden. Dies liegt daran, dass der Schlaf direkt nach dem Empfang des Signals vom Neuladen zurückkehrt:
<?php sleep(11); echo "foo"; sleep(11); echo "bar"; ?>
Führen Sie die vorherigen experimentellen Schritte erneut aus und Sie werden feststellen, dass der Fehler 502 erneut auftritt. Dies liegt daran, dass das Neuladen zwar dazu führt, dass der erste Schlaf sofort endet, der zweite Schlaf jedoch weiterhin gültig ist und das Zeitlimit von
process_control_timeout
überschreitet. Wenn wir
process_control_timeout
auf 12s setzen, dann ist alles wieder in Ordnung.
Auf diese Weise müssen wir nur einen angemessenen Wert für
process_control_timeout
festlegen, um einen reibungslosen Nachladevorgang sicherzustellen. Aber was ist ein angemessener Wert? Wenn es zu klein ist, ist es möglicherweise nicht wirksam. Wenn es zu groß ist, kann es zu Nebenwirkungen kommen? Wiederholen wir das letzte Experiment mit Fragen, aber dieses Mal fügen wir einen weiteren Monitor hinzu:
shell> watch -n1 'ps aux | grep php[-]fpm'
Der Zweck dieses Monitors besteht darin, die Änderungen des Neuladevorgangs zu beobachten in der Anzahl der PHP-FPM-Prozesse Um den Effekt deutlicher zu machen, wird empfohlen, den Startmodus von PHP-FPM in den statischen Modus zu ändern und gleichzeitig die Anzahl der Prozesse nicht zu groß zu machen.
Als wir das letzte Experiment wiederholten, stellten wir fest, dass außer dem Prozess, der die Anfrage ausführte, andere Prozesse direkt beendet wurden und der neue Prozess nicht sofort gestartet wurde und bis zum letzten alten Prozess hängen blieb Danach schließt der neue Prozess den Startvorgang ab. Wenn in diesem Zeitraum weitere Anfragen eingehen, wird diese zweifellos nicht sofort beantwortet.
Basierend auf unseren Experimenten können wir den Schluss ziehen, dass PHP-FPM standardmäßig keine reibungslose Ausführung des Neuladevorgangs garantieren kann und gleichzeitig ein angemessener
process_control_timeout
festgelegt werden muss Beachten Sie, dass der Wert nicht zu groß eingestellt werden darf, da das System sonst möglicherweise schwerwiegendere Probleme mit der Anforderungsüberlastung hat.
Zusammenfassung
Das Obige dreht sich alles um den Reload-Vorgang in PHP. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn). !