Si vous utilisez WordPress, WooCommerce, Magento, Shopware, Oxid, un CMS ou tout autre logiciel standard, le frontend et le backend utilisent généralement le même pool d'applications fpm. Même pour les applications auto-développées avec Symfony ou d'autres frameworks, c'est souvent le cas.
Le backend/administrateur peut donc inclure de nombreuses opérations lentes, des opérations administratives et des exports de données qui peuvent prendre beaucoup de temps. Cela pourrait encombrer la file d'attente de traitement des serveurs Web, réduisant ainsi le débit pour vos clients qui pourraient simplement cliquer sur le bouton de paiement et voir une erreur 502 Bad Gateway.
Mettre les frontends et les backends sur différents serveurs physiques est une solution, mais cela peut être trop coûteux pour la plupart des cas d'utilisation car nous doublons effectivement les coûts pour les deux machines ou instances.
Séparation du pool PHP-FPM entre le frontend et le backend
Une solution efficace pour éviter les goulots d’étranglement dans les applications Web consiste à configurer Pools PHP-FPM séparés pour le frontend et le backend, chacun avec des paramètres distincts pour la gestion des demandes et des ressources.
Pour comprendre le concept, imaginez gérer un bar avec une seule salle de bain partagée Entre clients et employés. À certains moments, comme lors d'une fête bondée, vous pouvez vous retrouver avec une longue file d'attente : le client doit attendre que l'employé ait terminé, et inversement. Cela génère inefficacités et mauvais service, ralentissant le travail du personnel et détériorant l’expérience client.
C'est pour cette raison que de nombreux endroits adoptent une division pratique : salles de bains séparées pour les clients et le personnel, afin d'éviter les interférences et les conflits d'utilisation.
De même, même dans l’environnement serveur, il est utile Ne mélangez pas le frontend et le backend dans le même pool PHP-FPMLes opérations effectuées par le backend, souvent plus lentes et plus intensives, comme les exportations de rapports ou les traitements administratifs, peuvent saturer les ressources et ralentir les réponses aux requêtes du frontend, qui sont plutôt liées à l'expérience utilisateur (chargement de page, paiement, connexion, etc.).
En séparant les deux environnements en pools distincts, on garantit que les opérations lentes du backend ne bloquent pas le trafic utilisateur du frontend, améliorant la stabilité, la réactivité et la qualité globale du service.
Exemple d'administration et de frontend Magento
De quoi ça a l'air? Prenons Magento comme exemple, vous pouvez configurer deux pools dans php-fpm.conf:
; php-fpm.conf [frontend] listen = /var/run/php-fpm-frontend.sock pm = statique pm.max_children = 50 [backend] listen = /var/run/php-fpm-backend.sock pm = ondemand pm.max_children = 5 pm.process_idle_timeout = 5
Le frontend est configuré pour jusqu'à 50 requêtes simultanées et le backend pour jusqu'à 5 requêtes simultanées. Les travailleurs principaux sont créés à la demande et les travailleurs frontaux sont statiques pour éviter les frais généraux. Je discuterai des différences entre les configurations de pool PHP-FPM dans un futur article de blog.
Vous pouvez ensuite modifier la configuration de l'hôte virtuel Nginx pour l'installation de Magento avec le commutateur suivant :
serveur { # Autres directives serveur... set $fpm_socket "unix:/var/run/php-fpm-frontend.sock"; if ($uri ~* "^/admin/") { set $fpm_socket "unix:/var/run/php-fpm-backend.sock"; } emplacement ~ \.php$ { # Autres directives FastCGI... inclure fastcgi_params; fastcgi_pass $fpm_socket; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } } Basé sur ^/adminpath dans l'uri de la requête, il sélectionnera désormais les différents pools PHP FPM et le frontend et le backend ne seront plus en concurrence et ne voleront plus les ressources de l'autre.
Si à la place nous travaillions avec WordPress ou WooCommerce, le chemin serait ^ / wp-admin.
Ce qui compte, c'est évidemment le concept qui le sous-tend, à savoir la possibilité de créer des files d'attente séparées et basées sur des chemins.
