Parlons brièvement de l'opération Reload en PHP

Avant-propos

De nombreuses personnes âgées nous ont prévenus que le rechargement peut garantir la fluidité de l'ensemble du processus. La soi-disant fluidité signifie que pendant le processus de rechargement, l'ancien processus y sera. il n’y aura pas de résiliation anticipée avant la demande en cours. Pendant de nombreuses années, je n'ai jamais remis en question cette affirmation jusqu'au jour où, lorsque j'ai rechargé, une erreur 502 s'est produite et j'ai dû y repenser.

Comment reproduire le problème ? Écrivons un script simple pour simuler :

<?php

sleep(11);
echo "foo";

?>

À ce stade, utilisez le navigateur pour parcourir cette URL, puis exécutez immédiatement le opération de rechargement. Vous pouvez voir l’erreur 502.

PHP est-il si faible ? Vous ne pouvez même pas garantir la fluidité de base du rechargement ? La réponse est bien sûr non, en fait notre objectif peut être atteint grâce aux paramètres

process_control_timeout

. Malheureusement, ce paramètre a la valeur par défaut 0, ce qui signifie qu'il ne prend pas effet. Cet article le définit sur 10s. Réexécutez les étapes expérimentales précédentes, et cette fois les résultats sont affichés normalement. Cependant, si vous faites quelques expériences supplémentaires, vous constaterez peut-être que le sommeil se termine immédiatement lorsque nous rechargeons. En effet, le sommeil revient directement après avoir reçu le signal du rechargement :

<.>

<?php

sleep(11);
echo "foo";
sleep(11);
echo "bar";

?>

Réexécutez les étapes expérimentales précédentes et vous constaterez que l'erreur 502 réapparaît. En effet, bien que le rechargement entraîne la fin immédiate du premier sommeil, le deuxième sommeil est toujours valide et dépasse la limite de temps de

process_control_timeout

. Si nous réglons

process_control_timeout

sur 12s, alors tout ira bien à nouveau.

De cette façon, il suffit de définir une valeur raisonnable pour

process_control_timeout

pour garantir la fluidité de l'opération de rechargement. Mais qu'est-ce qu'une valeur raisonnable ? S’il est trop petit, il risque de ne pas être efficace. S’il est trop important, y aura-t-il des effets secondaires ? Répétons la dernière expérience avec des questions, mais cette fois nous ajoutons un autre moniteur :

shell> watch -n1 'ps aux | grep php[-]fpm'

Le but de ce moniteur est d'observer le processus de rechargement. dans le nombre de processus PHP-FPM Afin de rendre l'effet plus évident, il est recommandé de changer le mode de démarrage de PHP-FPM en mode statique, et en même temps, le nombre de processus ne doit pas être trop élevé.

Lorsque nous avons répété la dernière expérience, nous avons constaté qu'à l'exception du processus qui exécutait la requête, d'autres processus étaient directement tués et que le nouveau processus n'était pas démarré immédiatement et qu'il restait bloqué jusqu'au dernier ancien processus. a été exécuté. Après cela, le nouveau processus termine le processus de démarrage. Durant cette période, si d’autres demandes arrivent, elles ne recevront sans doute pas de réponse immédiate.

Sur la base de nos expériences, nous pouvons conclure que par défaut, PHP-FPM ne peut pas garantir le bon déroulement de l'opération de rechargement, et qu'un

process_control_timeout

raisonnable doit être défini en même temps. , Notez que la valeur ne peut pas être définie sur une valeur trop élevée, sinon le système pourrait avoir des problèmes de congestion des demandes plus graves.

Résumé
Ce qui précède concerne l'opération de rechargement en PHP. Pour plus de contenu connexe, veuillez faire attention au site Web chinois PHP (www.php.cn). !