Séparez votre back-end lent du trafic frontal important avec PHP-FPM

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 simple à ce problème consiste à utiliser différents pools PHP-FPM pour le frontend et le backend, chacun avec sa propre configuration pour le nombre maximum de requêtes autorisées.

Par exemple, imaginez que vous êtes propriétaire d'un bar et que vous n'avez qu'une seule salle de bain utilisée à la fois par les clients et les employés. Des situations désagréables peuvent se produire, dans lesquelles le client doit attendre que l'employé ait fini pour utiliser la salle de bain, ou le cas d'une très grande file d'attente de personnes, peut-être lors d'une fête, et l'employé qui doit nécessairement faire la queue et attendre son tour.

Vous comprenez qu'une telle dynamique crée des désagréments et des problèmes importants tant pour l'employé que pour le client. En effet, de ce fait il est désormais courant de voir des établissements publics équipés de toilettes réservées aux clients et de toilettes réservées aux salariés afin de ne pas avoir à "mélanger" les files d'attente et les priorités associées.

Le même principe peut être utilisé au niveau du serveur lorsque l'on veut séparer la partie frontend de la partie backend.

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 = static 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 :

server {     // ....

    set $fpm_socket "unix:/var/run/php-fpm-frontend.sock";

    if ($uri ~* "^/admin/") {         set $fpm_socket "unix:/var/run/php-fpm-backend.sock";     }

    location ~ .php$ {         // ...

        fastcgi_pass $fpm_socket;     } } 

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.