Une version non éditée de l'article a été initialement publiée sur haydenjames.io et est publiée ici avec la permission de son auteur .
En un mot, je vais vous parler de la meilleure façon de configurer PHP-FPM pour augmenter le débit, réduire la latence et une utilisation plus stable des ressources processeur et de la mémoire. Par défaut, la chaîne PM (gestionnaire de processus) en PHP-FPM est dynamique , et si vous n'avez pas assez de mémoire, il est préférable d'installer ondemand . Comparons 2 options de contrôle basées sur la documentation de php.net et voyons en quoi mon PM statique préféré en diffère pour une grande quantité 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, lorsque pm.start_servers est démarré lorsque le service démarre).
pm = statique - le nombre de processus enfants est fixe et spécifié par le paramètre pm.max_children .
Voir la liste complète des directives globales php-fpm.conf pour plus de détails .
Les similitudes du gestionnaire de processus PHP-FPM avec le contrôleur de fréquence du processeur
Cela peut sembler hors sujet, mais je vais le relier à la rubrique de configuration PHP-FPM. Celui qui au moins une fois n'a pas ralenti le processeur - sur un ordinateur portable, une machine virtuelle ou un serveur dédié. Rappelez-vous la mise à l'échelle de la fréquence du processeur? Ces options, disponibles pour nix et Windows, peuvent améliorer les performances et la réactivité du système en faisant passer le paramètre du contrôleur de processeur de ondemand à performance *. Cette fois, comparons les descriptions et examinons les similitudes:
Governor = ondemand - mise à l'échelle dynamique de la fréquence du processeur en fonction de la charge actuelle. Bascule rapidement sur la fréquence maximale, puis la réduit lorsque les périodes d'inactivité augmentent.
Gouverneur = conservateur = mise à l'échelle dynamique de la fréquence en fonction de la charge actuelle. Augmente et diminue la fréquence plus doucement que la demande.
Governor = performance - la fréquence est toujours maximale.
Voir la liste complète des paramètres du contrôleur de fréquence du processeur pour plus de détails.
Vous voyez la ressemblance? Je voulais montrer cette comparaison pour vous convaincre qu'il est préférable d'utiliser pm static pour PHP-FPM.
Pour un contrôleur de processeur, le paramètre de performance permet d'augmenter les performances en toute sécurité car il dépend presque entièrement de la limite du processeur du serveur. En plus de cela, bien sûr, il existe également des facteurs tels que la température, la charge de la batterie (dans un ordinateur portable) et d'autres effets secondaires du fonctionnement constant du processeur à 100%. Le réglage des performances offre les performances du processeur les plus rapides. Lisez, par exemple, le paramètre force_turbo dans le Raspberry Pi , avec lequel le panneau RPi utilisera le contrôle des performances , où l'amélioration des performances sera plus notable en raison de la faible vitesse d'horloge du processeur.
Utilisation de pm static pour maximiser les performances du serveur
Le paramètre statique PHP-FPM pm dépend largement de la mémoire disponible sur le serveur. Si la mémoire est faible, il est préférable de choisir ondemand ou dynamique . D'un autre côté, si vous avez de la mémoire, vous pouvez éviter la surcharge du gestionnaire de processus PHP en définissant pm static sur la capacité maximale du serveur. En d'autres termes, si tout est bien calculé, vous devez définir pm.static sur la quantité maximale de processus PHP-FPM pouvant être exécutés sans créer de problèmes avec une mémoire ou un cache insuffisant. Mais pas assez pour surcharger les processeurs et accumuler un tas d'opérations PHP-FPM en attente d'exécution .
Dans la capture d'écran ci-dessus, pm = static et pm.max_children = 100 sont installés sur le serveur, ce qui prend environ 10 Go sur les 32 disponibles. Faites attention aux colonnes en surbrillance, tout est clair ici. Dans 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 toujours inactifs. Cela signifie que PHP-FPM est toujours défini sur la quantité maximale de ressources du serveur, quel que soit le trafic actuel. Un processus inactif attend les pics de trafic et répond instantanément. Vous n'avez pas besoin d'attendre pm pour créer des processus enfants, puis les terminer lorsque la période pm.process_idle_timeout expire . J'ai défini une valeur très élevée pour pm.max_requests , car c'est un serveur qui fonctionne sans fuite de mémoire en PHP. Vous pouvez définir pm.max_requests = 0 avec statique si vous êtes entièrement confiant dans les scripts PHP existants et futurs. Mais il est préférable de redémarrer les scripts au fil du temps. Installez un grand nombre de requêtes, car nous voulons éviter la surcharge inutile de pm. Par exemple, au moins pm.max_requests = 1000 - selon le nombre de pm.max_children et le nombre de demandes par seconde.
La capture d'écran montre la commande Linux top , filtrée par u (utilisateur) et le nom d'utilisateur PHP-FPM. Seuls les quelque 50 premiers processus sont affichés (je n'ai pas exactement compté), mais, en fait, top affiche les statistiques les plus importantes qui sont placées dans la fenêtre du terminal. Dans ce cas, trié par% CPU (% CPU). Pour afficher les 100 processus PHP-FPM, exécutez la commande:
top -bn1 | grep php-fpm
Quand utiliser pm ondemand et dynamic
Si vous utilisez pm dynamic , vous obtenez des erreurs similaires:
WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children
Essayez de changer le paramètre, l'erreur n'ira nulle part, comme décrit dans cet article sur Serverfault . Dans ce cas, la valeur de pm.min était trop petite, et puisque le trafic Web change beaucoup et a des pics élevés et des baisses importantes, il est difficile de configurer correctement pm dynamic . Cela utilise généralement pm ondemand , comme indiqué dans le même message . Mais c'est encore pire, car ondemand met fin aux processus inactifs à zéro lorsqu'il y a peu ou pas de trafic du tout, et par conséquent, vous subirez toujours des coûts lorsque le trafic change. À moins, bien sûr, que vous n'ayez fixé un temps d'attente énorme. Et puis il vaut mieux utiliser pm.static + un nombre élevé de 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ù, par exemple, plus de 100 comptes cpanel et environ 200 domaines, et pm.static ou même dynamique ne me sauveraient pas. Ici, seule la demande est nécessaire, car plus des deux tiers des sites Web reçoivent peu ou pas de trafic, et avec la demande, 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 défini la valeur par défaut sur ondemand . Auparavant, lorsque la valeur par défaut était dynamique , PHP-FPM n'était pas du tout adapté aux serveurs partagés occupés. Beaucoup utilisaient suPHP car pm dynamique consommait de la mémoire même avec des pools inactifs et des comptes PHP-FPM cPanel. Très probablement, avec un bon trafic, vous ne serez pas hébergé sur un serveur avec un grand nombre de pools PHP-FPM (hébergement mutualisé).
Conclusion
Si vous utilisez PHP-FPM et que vous avez un trafic important, les gestionnaires de processus à la demande et dynamiques pour PHP-FPM limiteront la bande passante en raison de leurs coûts inhérents. Examinez votre système et configurez vos processus PHP-FPM pour correspondre à la capacité maximale de votre serveur. Définissez d' abord pm.max_children en fonction de l'utilisation maximale de pm dynamic ou ondemand , puis augmentez cette valeur au niveau où la mémoire et le processeur fonctionneront sans surcharge excessive. Vous remarquerez qu'avec pm statique , puisque tout est stocké en mémoire, les pics de trafic dans le temps entraîneront moins de pics pour le processeur, et les valeurs moyennes de charge du serveur et du processeur seront égalisées. La taille moyenne du processus PHP-FPM dépend du serveur Web et nécessite une configuration manuelle, de sorte que les gestionnaires de processus les plus automatisés - dynamiques et à la demande - sont plus populaires. J'espère que l'article vous a été utile.
UPD Ajouté diagramme de référence ab . Si les processus PHP-FPM sont en mémoire, les performances sont améliorées en consommant la mémoire là où ils se trouvent et attendent. Trouvez la meilleure option pour vous.
