Apache vs Nginx per PrestaShop: Quale server web offre prestazioni migliori

Perché la scelta del server web è importante per PrestaShop

PrestaShop è un'applicazione PHP che genera pagine HTML dinamicamente, serve risorse statiche come immagini, file CSS e JavaScript e gestisce richieste AJAX sia dal front office che dal back office. Il server web si trova tra i visitatori e l'applicazione PHP, gestendo ogni singola richiesta HTTP. La sua architettura influisce direttamente sul numero di visitatori simultanei che il negozio può gestire, sulla velocità di caricamento delle pagine e sulla quantità di memoria del server consumata da ciascun visitatore.

Apache e Nginx sono i due server web dominanti per l'hosting di PrestaShop. Apache è stata la scelta predefinita fin dalle prime versioni di PrestaShop, e PrestaShop viene fornito con file .htaccess progettati specificamente per Apache. Nginx ha guadagnato un'adozione massiccia nell'ultimo decennio grazie alla sua gestione superiore delle connessioni simultanee e al minor consumo di memoria. Entrambi possono eseguire PrestaShop in modo efficace, ma differiscono in modi che contano per le prestazioni del negozio, la complessità della configurazione e il sovraccarico operativo.

Architettura: Modello a processi vs Loop di eventi

La differenza fondamentale tra Apache e Nginx sta nel modo in cui gestiscono le connessioni in ingresso. Questa differenza architetturale determina ogni differenza prestazionale tra i due server.

Il modello a processi/thread di Apache

Apache utilizza tradizionalmente un modello basato su processi tramite il suo prefork MPM (Multi-Processing Module). In questo modello, Apache crea un pool di processi worker e ciascun processo gestisce una richiesta alla volta. Quando arriva una richiesta, le viene assegnato un processo. Quel processo legge la richiesta, esegue il codice PHP (se si utilizza mod_php), invia la risposta e solo allora diventa disponibile per la richiesta successiva.

Il worker MPM utilizza thread anziché processi separati, consentendo più connessioni simultanee con meno memoria. L'event MPM va oltre, utilizzando un approccio basato sugli eventi per le connessioni keepalive pur continuando a utilizzare thread per l'elaborazione attiva delle richieste. Le installazioni moderne di Apache tipicamente utilizzano l'event MPM, ma il modello fondamentale prevede ancora la dedicazione di un thread a ciascuna richiesta attiva.

L'implicazione pratica è che la concorrenza di Apache è limitata dal numero di thread o processi worker configurati. Se configuri 150 worker e arrivano 151 richieste simultaneamente, l'ultima attende in coda. Ogni worker consuma memoria (tipicamente 10-30 MB per processo con mod_php, meno con PHP-FPM), quindi il numero massimo di worker è vincolato dalla RAM disponibile.

Il modello event-driven di Nginx

Nginx utilizza un'architettura asincrona basata sugli eventi. Un piccolo numero di processi worker (tipicamente uno per core della CPU) gestisce migliaia di connessioni simultaneamente utilizzando un event loop. Quando arriva una richiesta, Nginx la elabora in modo non bloccante. Se Nginx deve attendere qualcosa (una risposta da PHP-FPM, una lettura di file dal disco, una risposta da un server backend), non blocca il worker. Invece, passa a gestire altre connessioni e ritorna quando l'operazione attesa si completa.

Questo significa che un processo worker Nginx che gestisce 1.000 connessioni simultanee utilizza approssimativamente la stessa memoria di quando ne gestisce 10. Il consumo di memoria è determinato dal numero di processi worker (una manciata), non dal numero di connessioni (potenzialmente migliaia). Ecco perché Nginx eccelle sotto alta concorrenza ed è la scelta preferita per i siti ad alto traffico.

.htaccess vs configurazione del server

Una delle differenze pratiche più significative tra Apache e Nginx riguarda il modo in cui vengono gestite la riscrittura degli URL, il controllo degli accessi e altre configurazioni per directory.

Apache e .htaccess

Apache supporta i file .htaccess, che sono file di configurazione per directory che possono sovrascrivere le impostazioni a livello di server. PrestaShop fa ampio affidamento su .htaccess per la riscrittura degli URL amichevoli, il controllo degli accessi, gli header di caching e gli header di sicurezza. Quando abiliti gli URL amichevoli in PrestaShop, viene generato un file .htaccess con regole mod_rewrite che traducono URL puliti come /shoes/running-shoe nell'URL interno del dispatcher.

Il vantaggio di .htaccess è la comodità. Non hai bisogno dell'accesso root per modificare il comportamento del server web, e le modifiche hanno effetto immediato senza riavviare il server. PrestaShop può scrivere il proprio file .htaccess dal back office, il che significa che funzionalità come URL amichevoli, configurazione del media server e determinate impostazioni di sicurezza funzionano immediatamente.

Lo svantaggio è la prestazione. Ogni richiesta fa sì che Apache cerchi e analizzi i file .htaccess in ogni directory dalla document root alla directory del file richiesto. In una tipica richiesta PrestaShop, Apache potrebbe controllare la presenza di .htaccess in /, /var, /var/www, /var/www/html e oltre. Questo aggiunge I/O su disco e tempo di elaborazione a ogni richiesta. Per un sito che gestisce centinaia di richieste al secondo, questo overhead è misurabile.

Se hai accesso root alla configurazione di Apache, puoi spostare tutte le direttive .htaccess nella configurazione del VirtualHost e disabilitare l'elaborazione di .htaccess con AllowOverride None. Questo elimina l'overhead per richiesta mantenendo la stessa funzionalità. Tuttavia, le modifiche richiedono un reload di Apache per avere effetto.

Configurazione di Nginx

Nginx non supporta i file .htaccess. Tutta la configurazione risiede nei file di configurazione dei blocchi server, tipicamente sotto /etc/nginx/sites-available/ o /etc/nginx/conf.d/. Ogni regola di riscrittura URL, direttiva di controllo degli accessi e header di caching deve essere definita in questi file.

Questo significa che quando configuri PrestaShop su Nginx, devi tradurre manualmente le regole .htaccess di PrestaShop nella sintassi di configurazione di Nginx. Le regole di riscrittura sono fondamentalmente diverse tra i due server. Apache utilizza RewriteRule con pattern regex e flag come [L,R=301], mentre Nginx utilizza blocchi location con direttive try_files, rewrite e return.

Il vantaggio della configurazione centralizzata è la prestazione (nessuna scansione di file per richiesta) e la chiarezza (tutte le regole in un unico posto). Lo svantaggio è che PrestaShop non può generare la configurazione Nginx per te. Devi scriverla e mantenerla tu stesso, e ogni modifica richiede l'esecuzione di nginx -t per testare la sintassi e systemctl reload nginx per applicarla.

Integrazione PHP

Entrambi i server web devono eseguire codice PHP per generare le pagine PrestaShop. Il metodo di integrazione PHP influisce sulle prestazioni, la stabilità e la gestione delle risorse.

Apache con mod_php

L'approccio tradizionale è Apache con mod_php, dove PHP viene eseguito come modulo all'interno di ciascun processo Apache. Questo è semplice da configurare e non ha overhead di comunicazione tra processi perché PHP viene eseguito nello stesso processo che gestisce la richiesta HTTP. Tuttavia, ogni processo worker Apache porta in memoria l'intero runtime PHP, anche quando serve file statici come immagini o CSS. Questo spreca memoria perché la maggior parte delle richieste a un negozio PrestaShop riguarda risorse statiche, non pagine PHP.

Apache o Nginx con PHP-FPM

PHP-FPM (FastCGI Process Manager) esegue PHP come un pool di processi separato. Il server web comunica con PHP-FPM tramite un socket Unix o una connessione TCP utilizzando il protocollo FastCGI. Quando una richiesta richiede l'elaborazione PHP, il server web la inoltra a PHP-FPM. Quando l'elaborazione PHP è completata, PHP-FPM restituisce il risultato al server web, che lo invia al client.

Con PHP-FPM, i processi del server web che gestiscono file statici non portano il runtime PHP, risparmiando una quantità significativa di memoria. PHP-FPM offre anche la propria gestione dei processi con funzionalità come il dimensionamento dinamico del pool, lo slow log (registrazione quando una richiesta supera una soglia di tempo) e la possibilità di eseguire più versioni PHP simultaneamente per siti diversi.

Nginx utilizza esclusivamente PHP-FPM perché la sua architettura event-driven è incompatibile con l'incorporamento di PHP. Apache può utilizzare PHP-FPM tramite mod_proxy_fcgi. Nelle implementazioni moderne, PHP-FPM è l'approccio raccomandato per entrambi i server.

Configurazione PHP-FPM per PrestaShop

Indipendentemente dal server web scelto, la configurazione di PHP-FPM influisce significativamente sulle prestazioni di PrestaShop. Le impostazioni chiave includono:

pm = dynamic è solitamente la modalità migliore del process manager. Avvia un numero base di worker e ne crea altri sotto carico, fino a un massimo configurato. Questo bilancia il consumo di memoria e la reattività.

pm.max_children determina il numero massimo di processi PHP. Ogni richiesta PrestaShop tipicamente utilizza 30-80 MB di memoria, quindi dividi la RAM disponibile (meno ciò che servono il server web e il sistema operativo) per 80 per ottenere un massimo conservativo. Per un server con 4 GB di RAM utilizzabile, 50 processi figlio è un punto di partenza ragionevole.

pm.max_requests = 500 ricicla ciascun worker dopo 500 richieste, prevenendo l'accumulo di memory leak. I moduli PrestaShop occasionalmente presentano piccoli memory leak, e questa impostazione impedisce che diventino un problema.

Servizio di file statici

Un negozio PrestaShop serve grandi quantità di file statici: immagini dei prodotti, fogli di stile CSS, file JavaScript, font e upload multimediali. Le prestazioni del servizio di file statici influiscono direttamente sui tempi di caricamento delle pagine e sull'utilizzo delle risorse del server.

Prestazioni dei file statici di Apache

Apache serve i file statici attraverso i suoi processi worker. Ogni richiesta di file statico occupa un worker per la durata del trasferimento. Per file piccoli (CSS, JS, immagini piccole), questo è rapido. Per file grandi o connessioni client lente, il worker è impegnato più a lungo. Con mod_php caricato, ogni worker porta un overhead di memoria PHP non necessario anche per le richieste statiche.

Apache supporta sendfile, che consente al kernel di trasferire file direttamente dal disco al socket di rete senza copiare i dati attraverso lo spazio utente. Questo è abilitato per impostazione predefinita e aiuta con i trasferimenti di file grandi. Apache supporta anche la negoziazione del contenuto, i range di byte e le richieste condizionali (If-Modified-Since) nativamente.

Prestazioni dei file statici di Nginx

Nginx eccelle nel servizio di file statici perché il suo modello event-driven può gestire migliaia di trasferimenti di file simultanei senza aumentare proporzionalmente l'utilizzo delle risorse. Un singolo processo worker Nginx può servire centinaia di richieste di file statici simultanee. Combinato con l'uso efficiente della chiamata di sistema sendfile e il supporto integrato per la cache dei file aperti (caching dei descrittori di file per file accessibili frequentemente), il servizio di file statici è straordinariamente veloce.

Per i negozi PrestaShop con molte immagini di prodotto (che sono la maggior parte dei negozi), il vantaggio prestazionale di Nginx nel servizio dei file statici è significativo. Le pagine prodotto con 5-10 immagini, più file CSS, JavaScript e font, generano 20-30 richieste di file statici per caricamento pagina. Con traffico elevato, Nginx gestisce queste richieste con risorse sostanzialmente inferiori rispetto ad Apache.

Terminazione SSL/TLS

Ogni negozio PrestaShop dovrebbe funzionare su HTTPS, e il server web gestisce la crittografia e la decrittografia SSL/TLS (terminazione). Entrambi i server supportano bene il TLS moderno, ma ci sono differenze nella configurazione e nelle prestazioni.

Apache configura SSL tramite mod_ssl, con direttive come SSLEngine on, SSLCertificateFile e SSLProtocol nel blocco VirtualHost. Lo stapling OCSP, il caching delle sessioni e la selezione delle suite di cifratura sono tutti configurabili.

Nginx configura SSL nel blocco server con direttive come ssl_certificate, ssl_protocols e ssl_ciphers. Nginx supporta anche lo stapling OCSP e il caching delle sessioni, e la sua configurazione tende ad essere più concisa.

Dal punto di vista prestazionale, l'handshake TLS è intensivo a livello di CPU a causa della crittografia asimmetrica coinvolta. La capacità di Nginx di gestire molte connessioni simultanee con pochi processi worker significa che può gestire più handshake TLS al secondo con meno memoria. Per i negozi che ricevono grandi picchi di nuovi visitatori (durante una vendita, ad esempio), il vantaggio prestazionale TLS di Nginx può prevenire l'accodamento delle connessioni.

Reverse proxy e bilanciamento del carico

Per i negozi PrestaShop ad alto traffico, un'architettura reverse proxy separa le responsabilità e migliora la scalabilità. La configurazione più comune utilizza Nginx come reverse proxy davanti ad Apache o a un'altra istanza Nginx con PHP-FPM.

Nginx come reverse proxy per Apache

Questa configurazione ibrida combina i punti di forza di entrambi i server. Nginx si posiziona davanti, gestendo tutte le connessioni in ingresso, servendo i file statici direttamente, gestendo la terminazione SSL e inoltrando solo le richieste PHP ad Apache. Apache gestisce l'elaborazione PHP, e poiché riceve solo richieste PHP (non richieste di file statici), necessita di molti meno processi worker.

Questa architettura offre l'efficienza di gestione delle connessioni di Nginx e le prestazioni sui file statici, preservando al contempo il supporto .htaccess di Apache per le regole di riscrittura generate da PrestaShop. È un percorso di migrazione comune per i negozi che vogliono le prestazioni di Nginx senza riscrivere tutta la configurazione Apache.

La configurazione proxy di Nginx utilizza la direttiva proxy_pass per inoltrare le richieste ad Apache, tipicamente in esecuzione su una porta non standard come 8080. I file statici vengono serviti direttamente da Nginx utilizzando un blocco location che corrisponde alle estensioni dei file come .jpg, .css, .js e .png.

Configurazione completa Nginx

Per le massime prestazioni, Nginx serve tutto: file statici e richieste PHP (tramite PHP-FPM). Non c'è Apache nello stack. Questo elimina la comunicazione tra processi tra Nginx e Apache e rimuove l'overhead di memoria dell'esecuzione di due server web. Tuttavia, richiede la creazione e la manutenzione manuale della configurazione Nginx per la riscrittura degli URL di PrestaShop, che comporta più lavoro iniziale.

Configurazione Nginx raccomandata per PrestaShop

Una configurazione Nginx di produzione per PrestaShop deve gestire URL amichevoli, accesso al pannello di amministrazione, caching dei file statici, comunicazione con PHP-FPM e sicurezza. Gli elementi chiave includono un blocco server in ascolto sulle porte 80 e 443, un blocco di configurazione SSL con i certificati, una direttiva root che punta all'installazione di PrestaShop e diversi blocchi location.

Il blocco location principale utilizza try_files $uri $uri/ /index.php?$args per gestire gli URL amichevoli di PrestaShop. Questo tenta di servire la richiesta come file statico prima, poi come directory, e infine la passa al dispatcher di PrestaShop tramite index.php.

Un blocco location che corrisponde a ~ \.php$ inoltra le richieste PHP a PHP-FPM utilizzando fastcgi_pass. Include i parametri FastCGI standard e imposta SCRIPT_FILENAME sul percorso corretto.

Un blocco location per le risorse statiche imposta header di scadenza cache lunghi e disabilita il logging degli accessi per ridurre l'I/O. Pattern di corrispondenza come \.(jpg|jpeg|gif|png|svg|css|js|ico|woff|woff2|ttf|eot)$ catturano i tipi di file statici comuni.

I blocchi location relativi alla sicurezza negano l'accesso a file e directory sensibili: .htaccess, .git, config/ (eccetto config/xml/ di cui PrestaShop ha bisogno), vendor/, app/config/ e altre directory che non dovrebbero mai essere accessibili via web.

Configurazione Apache raccomandata per PrestaShop

Apache con event MPM e PHP-FPM fornisce il miglior hosting PrestaShop basato su Apache. La configurazione VirtualHost dovrebbe abilitare i moduli rewrite, headers, expires, deflate e proxy_fcgi.

Il DocumentRoot punta all'installazione di PrestaShop. AllowOverride All abilita l'elaborazione di .htaccess, necessaria a meno che non si spostino tutte le regole di riscrittura di PrestaShop nella configurazione del VirtualHost.

L'integrazione PHP-FPM utilizza SetHandler o ProxyPassMatch per inoltrare le richieste .php al socket PHP-FPM. L'approccio SetHandler con proxy:unix:/run/php/php-fpm.sock|fcgi://localhost è più semplice ed è raccomandato per la maggior parte delle configurazioni.

Abilita la compressione gzip con mod_deflate per i tipi di contenuto testuali: HTML, CSS, JavaScript, JSON, XML e SVG. Abilita il caching del browser con mod_expires, impostando tempi di scadenza lunghi per le risorse statiche e più brevi per HTML.

Benchmark prestazionali e differenze nel mondo reale

I numeri grezzi dei benchmark variano enormemente in base all'hardware, alla configurazione, alla versione PHP e alla versione PrestaShop. Piuttosto che presentare numeri specifici che sarebbero fuorvianti fuori contesto, ecco i pattern che emergono costantemente nei benchmark di hosting PrestaShop.

Per il servizio di file statici, Nginx è costantemente 2-3 volte più veloce di Apache e utilizza significativamente meno memoria. Questo divario si allarga all'aumentare della concorrenza. A 100 connessioni simultanee, la differenza potrebbe essere del 20%. A 1.000 connessioni simultanee, Nginx potrebbe utilizzare 10 volte meno memoria.

Per l'elaborazione delle richieste PHP, il server web non è il collo di bottiglia. Il tempo di elaborazione PHP-FPM domina il ciclo di vita della richiesta, ed entrambi i server web aggiungono un overhead trascurabile rispetto al tempo che PHP impiega per eseguire il codice PrestaShop, interrogare il database e renderizzare i template. La differenza nella gestione delle richieste PHP tra Apache con PHP-FPM e Nginx con PHP-FPM è tipicamente inferiore al 5%, che rientra nel margine di errore di misurazione per la maggior parte dei negozi.

Per i carichi di lavoro misti (lo scenario realistico), il vantaggio di Nginx deriva dalla sua gestione efficiente dei file statici insieme alle richieste PHP. Il caricamento di una pagina genera una richiesta PHP e 20-30 richieste di file statici. Nginx gestisce le 20-30 richieste statiche con un consumo di risorse trascurabile, mentre Apache assegna un thread worker a ciascuna. Con traffico elevato, questa differenza nel consumo di risorse significa che Nginx può sostenere una concorrenza più alta prima che le prestazioni degradino.

La conclusione pratica è che per i negozi con meno di 50 visitatori simultanei, la scelta del server web non fa quasi nessuna differenza percepibile. Per i negozi che si avvicinano o superano i 100 visitatori simultanei, i vantaggi architetturali di Nginx diventano significativi.

Guida alla migrazione: da Apache a Nginx

La migrazione di un negozio PrestaShop esistente da Apache a Nginx comporta la traduzione della configurazione, test approfonditi e lo switchover.

Passaggio 1: Traduci le regole .htaccess

Apri il tuo file .htaccess di PrestaShop e identifica tutte le regole di riscrittura attive. La sezione critica è la riscrittura degli URL amichevoli, che tipicamente inizia con RewriteCond %{REQUEST_FILENAME} !-f e RewriteRule .* - [E=REWRITEBASE:/]. Queste si traducono nella direttiva try_files di Nginx menzionata nella sezione di configurazione sopra.

Le riscritture del media server, la gestione dei prefissi di lingua e qualsiasi redirect personalizzato necessitano anch'essi di traduzione. Ogni coppia RewriteRule e RewriteCond di Apache deve essere convertita nella corrispondente direttiva location, rewrite o return di Nginx.

Passaggio 2: Configura Nginx accanto ad Apache

Installa Nginx e configuralo per ascoltare su una porta diversa (come 8080) mentre Apache continua a funzionare sulla porta 80. Questo ti permette di testare la configurazione Nginx senza influenzare il sito in produzione. Punta Nginx alla stessa document root di Apache in modo che serva gli stessi file.

Passaggio 3: Testa tutto

Accedi al sito tramite la porta di Nginx e testa ogni aspetto: la home page, le pagine delle categorie, le pagine dei prodotti, il carrello, il checkout, il pannello di amministrazione, gli URL amichevoli, il caricamento delle immagini e il routing multilingua degli URL. Presta particolare attenzione ai pattern di URL che coinvolgono caratteri speciali o parametri di query.

Passaggio 4: Effettua lo switch

Una volta completati i test, ferma Apache e riconfigura Nginx per ascoltare sulle porte 80 e 443. Ricarica Nginx e verifica che il sito in produzione funzioni correttamente. Mantieni la configurazione di Apache intatta per alcuni giorni nel caso in cui sia necessario fare un rollback.

Problemi comuni nella migrazione

Il problema più comune sono le regole di riscrittura mancanti per il routing multilingua degli URL di PrestaShop. Se il tuo negozio utilizza più lingue con codici di lingua nell'URL (come /en/, /de/, /fr/), assicurati che la configurazione Nginx gestisca correttamente questi prefissi.

Un altro problema comune sono i limiti di dimensione per l'upload dei file. Apache utilizza LimitRequestBody mentre Nginx utilizza client_max_body_size. Se importi prodotti con immagini grandi, imposta client_max_body_size ad almeno 20M.

Le richieste AJAX del pannello di amministrazione che si basano sulla riscrittura di .htaccess possono interrompersi se le regole Nginx corrispondenti sono mancanti. Testa il pannello di amministrazione accuratamente, inclusa la modifica dei prodotti, la gestione degli ordini e la configurazione dei moduli.

Quale dovresti scegliere

Scegli Apache se ti trovi su un hosting condiviso dove non controlli il server web, se fai ampio affidamento su .htaccess per la configurazione (regole generate dai moduli, plugin di sicurezza) o se non ti senti a tuo agio nello scrivere e mantenere file di configurazione Nginx. Apache con event MPM e PHP-FPM è una configurazione solida e ben supportata per i negozi PrestaShop con traffico moderato.

Scegli Nginx se hai accesso root al tuo server, il tuo negozio gestisce un traffico significativo (centinaia o migliaia di visitatori simultanei), vuoi il consumo di risorse più basso possibile per un dato livello di traffico o stai configurando un nuovo server e preferisci i benefici a lungo termine dell'architettura Nginx. Lo sforzo iniziale di configurazione è un costo una tantum che ripaga in termini di prestazioni ed efficienza delle risorse.

Scegli l'approccio del reverse proxy Nginx davanti ad Apache se vuoi le prestazioni di Nginx per i file statici e la gestione delle connessioni ma hai bisogno del supporto .htaccess di Apache per la compatibilità con i moduli PrestaShop che generano o dipendono dalle regole .htaccess.

Per la maggior parte delle nuove installazioni PrestaShop su un VPS o server dedicato, Nginx con PHP-FPM è la scelta raccomandata. La configurazione è ben documentata, i vantaggi prestazionali sono reali e la semplicità operativa di un singolo stack web server riduce l'overhead di manutenzione. Per i negozi esistenti su Apache che funzionano adeguatamente, la migrazione a Nginx è un'ottimizzazione utile ma non una necessità urgente, a meno che non si stiano raggiungendo i limiti di prestazione.