Se stai usando WordPress, WooCommerce, Magento, Shopware, Oxid, un CMS o qualsiasi altro software standard, di solito sia il frontend che il backend utilizzano lo stesso pool fpm applicativo. Anche per le applicazioni sviluppate autonomamente con Symfony o altri framework questo è spesso il caso.
Il back-end/amministratore può quindi includere numerose operazioni lente, operazioni amministrative ed esportazioni di dati che possono richiedere molto tempo. Ciò potrebbe congestionare la coda di elaborazione dei server web riducendo il throughput per i tuoi clienti che potrebbero semplicemente fare clic sul pulsante di pagamento e visualizzare un errore 502 Bad Gateway.
Mettere frontend e backend su server fisici diversi è una soluzione, ma può essere troppo costoso per la maggior parte dei casi d’uso visto che andremo di fatto a raddoppiare i costi per le due macchine o istanze.
Separazione Pool PHP-FPM tra frontend e backend
Una soluzione efficace per evitare colli di bottiglia nelle applicazioni web consiste nel configurare pool PHP-FPM separati per il frontend e il backend, ognuno con parametri distinti per la gestione delle richieste e delle risorse.
Per comprendere il concetto, immagina di gestire un bar con un solo bagno condiviso tra clienti e dipendenti. In certi momenti, come durante una festa affollata, potresti trovarti con una lunga fila: il cliente deve attendere che il dipendente finisca, e viceversa. Questo genera inefficienze e disservizi, rallentando il lavoro del personale e peggiorando l’esperienza del cliente.
È per questo motivo che molti locali adottano una divisione pratica: bagni separati per clienti e staff, così da evitare interferenze e conflitti d’uso.
Allo stesso modo, anche in ambito server, è utile non mescolare frontend e backend nello stesso pool PHP-FPM. Le operazioni eseguite dal backend — spesso più lente e intensive, come esportazioni di report o elaborazioni amministrative — possono saturare le risorse e rallentare le risposte alle richieste del frontend, che sono invece legate all’esperienza utente (caricamento pagine, checkout, login, ecc.).
Separando i due ambienti in pool distinti, si garantisce che le operazioni lente del backend non blocchino il traffico utente del frontend, migliorando stabilità, reattività e qualità complessiva del servizio.
Esempio di amministrazione e frontend Magento
Come appare? Usiamo Magento come esempio, puoi configurare due pool in 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
Il frontend è configurato per un massimo di 50 richieste simultanee e il backend per un massimo di 5 richieste simultanee. I lavoratori di back-end vengono creati su richiesta e i lavoratori di front-end sono statici per evitare il fork overhead. Discuterò le differenze tra le configurazioni del pool PHP-FPM in un futuro post sul blog.
È quindi possibile modificare la configurazione di Nginx vhost per l’installazione di Magento con il seguente interruttore:
server {
# Altre direttive del 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$ {
# Altre direttive FastCGI...
include fastcgi_params;
fastcgi_pass $fpm_socket;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
} In base al ^/adminpercorso nell’uri della richiesta, selezionerà ora il diverso pool FPM PHP e frontend e backend non competeranno più e si ruberanno le risorse a vicenda.
Se invece lavorassimo con WordPress o WooCommerce il percorso sarebbe ^/wp-admin.
Ciò che conta è ovviamente il concetto alla base, ovvero la possibilità di creare code separate e basate su path.
