Configuration de PHP-FPM : utilisons pm static pour des performances maximales

La version non éditée de cet article a été initialement publiée sur haydenjames.io et est publiée ici avec la permission de son l'auteur.

Je vais brièvement expliquer comment configurer PHP-FPM pour augmenter le débit, réduire la latence et utiliser plus efficacement les ressources processeur et mémoire. Par défaut, la ligne PM (process manager, gestionnaire de processus) dans PHP-FPM est définie sur dynamic, et si vous manquez de mémoire, il vaut mieux définir ondemand. Comparons les deux options de gestion basées sur la documentation de php.net et voyons en quoi mon préféré diffère : static pm pour un fort volume de trafic :

pm = dynamic — le nombre de processus enfants est configuré dynamiquement en fonction des directives suivantes : pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — les processus sont créés à la demande (contrairement à la création dynamique, où pm.start_servers est lancé au démarrage du service).
pm = static — le nombre de processus enfants est fixe et spécifié par le paramètre pm.max_children.

Pour plus de détails, voir le liste complète des directives globales php-fpm.conf.

Similarités entre le gestionnaire de processus PHP-FPM et le régulateur de fréquence du processeur

Cela peut sembler hors sujet, mais je vais le relier au thème de la configuration de PHP-FPM. Qui n'a jamais rencontré de ralentissement du processeur — sur un ordinateur portable, une machine virtuelle ou un serveur dédié ? Vous vous souvenez de l'optimisation de la fréquence du processeur ? Ces paramètres, disponibles pour nix et Windows, peuvent améliorer les performances et la réactivité système si vous modifiez le paramètre du régulateur de processeur de ondemand sur performance*. Cette fois, comparons les descriptions et examinons les similarités :

Governor = ondemand — mise à l'échelle dynamique de la fréquence processeur en fonction de la charge actuelle. Passe rapidement à la fréquence maximale, puis la réduit lors de périodes d'inactivité.
Governor = conservative = mise à l'échelle dynamique de la fréquence en fonction de la charge actuelle. Augmente et diminue la fréquence plus doucement que ondemand.
Governor = performance — la fréquence est toujours maximale.

Pour plus de détails, voir le liste complète des paramètres du régulateur de fréquence du processeur.

Vous voyez la similarité ? Je voulais montrer cette comparaison pour vous convaincre que le mieux est d'utiliser pm static pour PHP-FPM.

Pour le régulateur de processeur, le paramètre performance aide à augmenter en toute sécurité les performances, car elle dépend presque entièrement de la limite du processeur du serveur. En plus de cela, il y a bien sûr d'autres facteurs, comme la température, la charge de la batterie (dans un ordinateur portable) et d'autres effets secondaires liés au fonctionnement constant du processeur à 100 %. La configuration de performance garantit le fonctionnement le plus rapide du processeur. Par exemple, lisez sur le paramètre force_turbo dans Raspberry Pi, avec lequel le panneau RPi utilisera le régulateur performance, où l'amélioration des performances sera plus perceptible en raison de la faible fréquence d'horloge du CPU.

L'utilisation de pm static pour atteindre des performances maximales du serveur

Le paramètre PHP-FPM pm static dépend en grande partie de la mémoire libre sur le serveur. S'il y a peu de mémoire, il vaut mieux choisir ondemand ou dynamic. D'un autre côté, si vous avez de la mémoire, vous pouvez éviter des coûts supplémentaires du gestionnaire de processus PHP, en configurant pm static à la capacité maximale du serveur. Autrement dit, si tout est bien calculé, il faut définir pm.static au maximum du nombre de processus PHP-FPM pouvant être exécutés, sans causer de problèmes de manque de mémoire ou de cache. Mais pas si haut que cela surcharge les processeurs et accumule une multitude d'opérations PHP-FPM en attente d'exécution.

Sur la capture d'écran ci-dessus, le serveur est configuré avec pm = static et pm.max_children = 100, et cela occupe environ 10 Go des 32 disponibles. Notez les colonnes surlignées, ici tout est clair. Sur cette capture d'écran, il y avait environ 200 utilisateurs actifs (plus de 60 secondes) dans Google Analytics. À ce niveau, environ 70 % des processus enfants PHP-FPM sont encore inactifs. Cela signifie que PHP-FPM est toujours configuré à la capacité maximale des ressources du serveur, indépendamment du trafic actuel. Le processus inactif attend les pics de trafic et réagit immédiatement. Vous n'avez pas à attendre que pm génère des processus enfants, puis les termine lorsque le délai pm.process_idle_timeoutexpire. J'ai défini une valeur très élevée pour pm.max_requests, car c'est un serveur de production sans fuites de mémoire en PHP. Vous pouvez définir pm.max_requests = 0 avec static, si vous êtes totalement convaincu des scripts PHP existants et futurs. Mais il est préférable de redémarrer les scripts de temps en temps. Définissez un nombre élevé de requêtes, car nous voulons éviter des coûts supplémentaires en pm. Par exemple, au moins pm.max_requests = 1000 — en fonction du nombre pm.max_children et du nombre de requêtes par seconde.

La capture d'écran montre la commande Linux top, filtré par u (utilisateur) et le nom d'utilisateur PHP-FPM. Seuls les 50 premiers processus (ou à peu près) sont affichés (je n'ai pas compté exactement), mais en gros, top montre les statistiques principales qui s'affichent dans la fenêtre du terminal. Dans ce cas, trié par % CPU (%CPU). Pour voir tous les 100 processus PHP-FPM, utilisez la commande :

top -bn1 | grep php-fpm

Quand utiliser pm ondemand et dynamic

Si vous utilisez pm dynamic, des erreurs similaires surviennent :

WARNING: [pool xxxx] semble occupé (vous devrez peut-être augmenter pm.start_servers, ou pm.min/max_spare_servers), générant 32 enfants, il y en a 4 inactifs, et 59 enfants au total

Essayez de modifier le paramètre, l'erreur ne disparaîtra pas, comme décrit dans ce post sur Serverfault. Dans ce cas, la valeur de pm.min était trop basse, et comme le trafic web varie considérablement avec des pics élevés et des baisses importantes, il est difficile de régler correctement pm dynamic. En général, on utilise pm ondemand, comme conseillé dans le même post. Mais c'est encore pire, car ondemand il termine les processus inactifs à zéro lorsque le trafic est faible ou inexistant, et au final vous aurez toujours des problèmes avec les variations de trafic. À moins, bien sûr, que vous n'ayez mis en place un temps d'attente élevé. Dans ce cas, il vaut mieux utiliser pm.static + un nombre élevé pm.max_requests.

PM dynamic et surtout ondemand peuvent être utiles si vous avez plusieurs pools PHP-FPM. Par exemple, vous hébergez plusieurs comptes cPanel ou plusieurs sites web dans différents pools. J'ai un serveur où, disons, il y a plus de 100 comptes cPanel et environ 200 domaines, et pm.static ou même dynamic ne m'aiderait pas. Ici, seul ondemand, car plus de deux tiers des sites web reçoivent peu ou pas de trafic, et avec ondemand tous les processus enfants tomberont, ce qui nous fera économiser beaucoup de mémoire ! Heureusement, les développeurs de cPanel l'ont remarqué et ont établi la valeur par défaut ondemand. Avant cela, lorsque la valeur par défaut était dynamic, PHP-FPM n'était pas du tout adapté pour les serveurs partagés fortement chargés. Beaucoup utilisaient suPHP, car pm dynamic consommait de la mémoire même avec des pools inactifs et des comptes cPanel PHP-FPM. Très probablement, en cas de bon trafic, vous ne serez pas hébergé sur un serveur avec un grand nombre de pools PHP-FPM (hébergement partagé).

Conclusion

Si vous utilisez PHP-FPM et que vous avez un trafic sérieux, les gestionnaires de processus ondemand et dynamic pour PHP-FPM limiteront la bande passante à cause des coûts qui leur sont inhérents. Analysez votre système et configurez les processus PHP-FPM selon la capacité maximale du serveur. D'abord, définissez pm.max_children en fonction de l'utilisation maximale du pm dynamic ou ondemand, puis augmentez cette valeur à un niveau où la mémoire et le processeur fonctionneront sans surcharge excessive. Vous remarquerez qu'avec pm static, étant donné que tout est stocké en mémoire, les pics de trafic au fil du temps provoqueront moins de pics pour le processeur, et les moyennes de charge du serveur et du processeur s'aligneront. La taille moyenne du processus PHP-FPM dépend du serveur web et nécessite un réglage manuel, c'est pourquoi des gestionnaires de processus plus automatisés sont dynamic et ondemand — plus populaires. J'espère que cet article a été utile.

MAJ Un diagramme de benchmark a été ajouté ab. Si les processus PHP-FPM sont en mémoire, la performance augmente grâce à la consommation de mémoire, où ils se trouvent et attendent. Trouvez l'option optimale pour vous.

Source : habr.com