Preparare un server per il Black Friday: checklist PHP-FPM, MySQL e cache NGINX

Il Black Friday 2026 cade venerdì 27 novembre. Due settimane prima — quindi entro venerdì 13 novembre — è il momento di aprire il terminale e controllare quattro punti che, sotto traffico, fanno la differenza tra un sito lento e un sito giù. Nessuna delle modifiche seguenti richiede hardware nuovo: sono parametri di configurazione che su molte installazioni di default restano quelli di una VPS con poche visite al giorno.

1. PHP-FPM: pm.max_children

È il numero massimo di processi PHP che il server può tenere in piedi insieme. Se è troppo basso, le richieste in eccedenza finiscono in coda e il TTFB sale; se è troppo alto, la RAM finisce prima che il traffico cali.

Per calcolarlo, prima si misura quanto pesa in media un processo PHP-FPM già attivo: il comando ps -ylC php-fpm --sort:rss mostra la memoria usata da ogni processo figlio, con il valore RSS espresso in kilobyte.

Poi si applica la formula: pm.max_children = RAM totale disponibile per PHP / dimensione media di un processo PHP. Un esempio pratico dalla stessa fonte: con 2000 MB di RAM disponibile e processi da circa 50 MB ciascuno, 2000/50 dà un pm.max_children di 40.

Il file da modificare è /etc/php/8.1/fpm/pool.d/www.conf su Ubuntu 22.04 (PHP 8.1 di default) e /etc/php/8.3/fpm/pool.d/www.conf su Ubuntu 24.04 (PHP 8.3 di default). Dopo la modifica: systemctl reload php8.1-fpm (o php8.3-fpm).

2. MySQL/MariaDB: max_connections

Ogni richiesta PHP che interroga il database apre una connessione. Dal 2010, con MySQL 5.5, il valore di default di max_connections è 151, lo stesso valore vale anche su MySQL 8.0.46 e MariaDB 10.11.14, le versioni incluse in Ubuntu 24.04. Durante un picco di checkout simultanei, 151 si esauriscono in fretta.

Si verifica con SHOW VARIABLES LIKE 'max_connections'; e si alza modificando, su Ubuntu/Debian, il file /etc/mysql/mariadb.conf.d/50-server.cnf, aggiungendo sotto [mysqld] la riga max_connections = 300 (o 500 se il server ha RAM sufficiente), seguita da systemctl restart mariadb. Attenzione: ogni connessione aperta consuma RAM aggiuntiva, va alzata insieme al controllo di pm.max_children, non al posto di quello.

3. Pagina statica di fallback

Se PHP-FPM satura i worker, NGINX risponde 502. Una pagina statica di emergenza (anche solo HTML con messaggio "carrello temporaneamente occupato, riprova tra pochi secondi") evita che l'utente veda l'errore nudo. In pratica si aggiunge nel blocco location un try_files $uri @fallback; con un blocco @fallback che serve un file statico da /var/www/maintenance.html quando il backend non risponde entro il timeout impostato con proxy_intercept_errors on; e error_page 502 503 504 /maintenance.html;.

4. Test del failover CDN

Non basta avere una CDN configurata: va provata prima del giorno. Si disattiva temporaneamente l'origine (o si simula un timeout) e si verifica con curl -I che la risposta arrivi comunque, controllando l'header di cache (es. X-Cache o equivalente del proprio fornitore) per capire se il contenuto viene servito dalla cache edge o fallisce insieme all'origine.

Riepilogo

Controllo	Comando di verifica	File da modificare
pm.max_children	ps -ylC php-fpm --sort:rss	/etc/php/8.1(o 8.3)/fpm/pool.d/www.conf
max_connections	SHOW VARIABLES LIKE 'max_connections';	/etc/mysql/mariadb.conf.d/50-server.cnf
Pagina statica	curl -I https://tuosito.it	blocco location in NGINX
Failover CDN	curl -I con origine disattivata	pannello del fornitore CDN

Ogni modifica va testata prima del 13 novembre, non il giorno del lancio della campagna.