Plesk PHP-FPM vs CGI: differenze e quale scegliere

I PHP handler in Plesk

Quando configuri un dominio in Plesk puoi scegliere come PHP elabora le richieste. La scelta dell'handler PHP impatta significativamente su performance, consumo di memoria, supporto di funzionalita' come .htaccess e separazione di sicurezza tra siti.

I principali handler disponibili sono:

• PHP-FPM by nginx
• PHP-FPM by Apache
• FastCGI
• CGI
• Apache module (mod_php)

CGI

Il Common Gateway Interface e' la modalita' più' vecchia. Per ogni richiesta HTTP, il web server lancia un nuovo processo PHP che elabora la richiesta e termina.

Vantaggi:

• Massima isolamento tra richieste
• Funziona ovunque, anche con permessi minimi

Svantaggi:

• Lento (overhead di fork per ogni richiesta)
• Alto consumo CPU
• Non adatto a produzione

CGI puro va usato solo per casi molto specifici di compatibilità'.

FastCGI

FastCGI risolve i problemi di CGI mantenendo i processi PHP in esecuzione e riutilizzandoli. Apache passa le richieste via socket Unix al processo FastCGI.

Vantaggi:

• Molto più' veloce di CGI
• Process pool riusato

Svantaggi:

• Spawning gestito da suexec o mod_fcgid: meno efficiente di FPM
• Configurazione meno granulare

PHP-FPM

PHP FastCGI Process Manager e' l'handler moderno e consigliato per produzione. FPM mantiene un pool di processi PHP sempre attivi, gestiti in modo intelligente con strategie dinamiche.

Vantaggi:

• Performance eccellenti
• Configurazione granulare per pool (pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers)
• Supporta status page per monitoring
• Restart graceful senza perdere richieste
• Slow query log per debugging

FPM puo' essere abbinato a:

• Apache: Apache passa via UDS a FPM. Supporta .htaccess.
• Nginx: Nginx parla direttamente con FPM via socket. Performance massime, ma .htaccess non supportato (regole vanno tradotte in Nginx config).

Apache module (mod_php)

PHP viene caricato come modulo dentro Apache. Ogni worker Apache puo' eseguire PHP senza fork esterni.

Vantaggi:

• Performance buone
• Configurazione semplice

Svantaggi critici:

• Nessun'isolamento: tutti i siti girano come utente Apache
• Aumenta il footprint di memoria di Apache
• Una versione PHP unica per tutto il server
• Insicuro in shared hosting

In Plesk, mod_php usa solo la versione PHP di sistema, non le Plesk PHP. Sconsigliato.

Quale scegliere

Linea guida per la scelta:

• Siti WordPress / Joomla / Drupal: PHP-FPM by Apache (supporta .htaccess che questi CMS usano)
• App custom Laravel/Symfony: PHP-FPM by nginx (massime performance)
• API JSON ad alto traffico: PHP-FPM by nginx
• Legacy WordPress senza permalink personalizzati: anche FastCGI puo' bastare
• NEVER: CGI in produzione, mod_php in shared hosting

Configurazione pool FPM

Plesk crea automaticamente un pool FPM per ogni dominio. Modificare i parametri da PHP Settings → espandere le opzioni avanzate:

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 10
pm.max_requests = 500

Su server con poca RAM ridurre pm.max_children: ogni worker FPM consuma 30-80 MB.

Monitorare PHP-FPM

Da SSH:

ps aux | grep php-fpm
systemctl status plesk-php83-fpm

Slow log per query lente:

tail -f /var/log/plesk-php-fpm/*.slowlog

Differenze di sicurezza

PHP-FPM esegue ogni dominio sotto un proprio utente di sistema (es. dominio_user). Mod_php esegue tutto sotto apache: un sito compromesso puo' accedere ai file di altri siti. Questa e' la ragione principale per cui mod_php e' sconsigliato in shared hosting.

Sessioni PHP

Le sessioni PHP sono salvate per default in /var/lib/php/sessions/. Con PHP-FPM e utenti separati, ogni dominio ha la sua directory di sessioni: /var/www/vhosts/dominio.it/tmp/. Risolve problemi di sicurezza session hijacking.

Apache vs Nginx come frontend

Quando Apache e' il frontend (con o senza FPM), supporta nativamente .htaccess: utile per WordPress, Joomla, regole rewrite per CMS legacy. Quando Nginx e' il frontend, .htaccess viene ignorato: le regole vanno tradotte in direttive Nginx in Apache & nginx Settings.

Benchmark indicativi

Su hardware comparabile, ApacheBench su una pagina WordPress homepage:

• CGI: ~30 req/s
• FastCGI: ~150 req/s
• mod_php: ~250 req/s
• PHP-FPM by Apache: ~280 req/s
• PHP-FPM by Nginx: ~350 req/s

I numeri sono indicativi e variano molto con la complessita' del sito.

Memoria consumata

FPM e' parsimonioso: ogni worker consuma 30-80 MB. mod_php carica PHP in ogni worker Apache (anche per richieste statiche): l'overhead aggregato e' maggiore.

Quando passare da FPM by Apache a FPM by Nginx

Per siti dove le performance sono critiche (e-commerce, traffico elevato) considerare la transizione. Step:

1. Backup configurazione
2. Identificare regole .htaccess critiche
3. Tradurre le regole in Nginx config (in Apache & nginx Settings → Additional nginx directives)
4. Switch dell'handler a FPM by Nginx
5. Test approfondito

Hybrid mode: Nginx proxy + Apache backend

Plesk supporta nativamente questa configurazione: Nginx fa da reverse proxy davanti ad Apache (che esegue PHP-FPM). Nginx serve i file statici direttamente, Apache gestisce PHP. Ottimo compromesso tra performance e compatibilità' .htaccess.

Tuning per WordPress

Per siti WordPress consigliamo:

• FPM by Apache (per .htaccess)
• opcache.memory_consumption=256M
• memory_limit=256M
• max_execution_time=120
• realpath_cache_size=4M

Conclusioni pratiche

Per la stragrande maggioranza dei casi d'uso moderni la scelta consigliata e' PHP-FPM. Apache+FPM offre il miglior compromesso per CMS tradizionali grazie al supporto .htaccess. Nginx+FPM massimizza performance per API e applicazioni custom.

Hai bisogno di aiuto?

Se vuoi gestione Plesk dal team di G Tech Group, scrivici tramite il modulo di contatto.