Apache vs Nginx pour PrestaShop : quel serveur web offre les meilleures performances

Pourquoi le choix du serveur web est important pour PrestaShop

PrestaShop est une application PHP qui génère dynamiquement des pages HTML, sert des ressources statiques comme les images, les fichiers CSS et JavaScript, et traite les requêtes AJAX provenant du front-office comme du back-office. Le serveur web se situe entre vos visiteurs et l'application PHP, gérant chaque requête HTTP. Son architecture affecte directement le nombre de visiteurs simultanés que votre boutique peut gérer, la vitesse de chargement des pages et la quantité de mémoire serveur consommée par chaque visiteur.

Apache et Nginx sont les deux serveurs web dominants pour l'hébergement de PrestaShop. Apache est le choix par défaut depuis les premières versions de PrestaShop, et PrestaShop est livré avec des fichiers .htaccess conçus spécifiquement pour Apache. Nginx a connu une adoption massive au cours de la dernière décennie grâce à sa gestion supérieure des connexions simultanées et à son empreinte mémoire réduite. Les deux peuvent exécuter PrestaShop efficacement, mais ils diffèrent sur des aspects importants pour les performances de la boutique, la complexité de la configuration et la charge opérationnelle.

Architecture : modèle de processus vs boucle d'événements

La différence fondamentale entre Apache et Nginx réside dans leur façon de gérer les connexions entrantes. Cette différence architecturale détermine chaque différence de performance entre les deux.

Le modèle de processus/threads d'Apache

Apache utilise traditionnellement un modèle basé sur les processus via son MPM Prefork (Multi-Processing Module). Dans ce modèle, Apache crée un pool de processus workers, et chaque processus gère une requête à la fois. Quand une requête arrive, un processus lui est assigné. Ce processus lit la requête, exécute le code PHP (en utilisant mod_php), envoie la réponse, et ne devient disponible pour la requête suivante qu'après cette opération.

Le MPM Worker utilise des threads au lieu de processus séparés, permettant plus de connexions simultanées avec moins de mémoire. Le MPM Event va plus loin en utilisant une approche événementielle pour les connexions keepalive tout en utilisant des threads pour le traitement actif des requêtes. Les installations Apache modernes utilisent typiquement le MPM Event, mais le modèle fondamental implique toujours la dédicace d'un thread à chaque requête active.

La conséquence pratique est que la concurrence d'Apache est limitée par le nombre de threads ou processus workers configurés. Si vous configurez 150 workers et que 151 requêtes arrivent simultanément, la dernière attend dans une file d'attente. Chaque worker consomme de la mémoire (typiquement 10 à 30 Mo par processus avec mod_php, moins avec PHP-FPM), de sorte que le nombre maximum de workers est contraint par la RAM disponible.

Le modèle événementiel de Nginx

Nginx utilise une architecture asynchrone pilotée par les événements. Un petit nombre de processus workers (typiquement un par cœur CPU) gère des milliers de connexions simultanément via une boucle d'événements. Quand une requête arrive, Nginx la traite de manière non bloquante. Si Nginx doit attendre quelque chose (une réponse de PHP-FPM, une lecture de disque, une réponse d'un serveur backend), il ne bloque pas le worker. Au lieu de cela, il passe au traitement d'autres connexions et revient quand l'opération en attente est terminée.

Cela signifie qu'un processus worker Nginx gérant 1 000 connexions simultanées utilise approximativement la même quantité de mémoire que pour 10 connexions. L'empreinte mémoire est déterminée par le nombre de processus workers (quelques-uns), et non par le nombre de connexions (potentiellement des milliers). C'est pourquoi Nginx excelle sous forte charge et pourquoi il est le choix préféré pour les sites à fort trafic.

.htaccess vs configuration serveur

L'une des différences pratiques les plus significatives entre Apache et Nginx concerne la gestion de la réécriture d'URL, le contrôle d'accès et les autres configurations par répertoire.

Apache et .htaccess

Apache prend en charge les fichiers .htaccess, qui sont des fichiers de configuration par répertoire pouvant remplacer les paramètres globaux du serveur. PrestaShop dépend fortement de .htaccess pour la réécriture des URL conviviales, le contrôle d'accès, les en-têtes de cache et les en-têtes de sécurité. Lorsque vous activez les URL conviviales dans PrestaShop, il génère un fichier .htaccess avec des règles mod_rewrite qui traduisent des URL propres comme /chaussures/chaussure-de-course en l'URL interne du dispatcher.

L'avantage de .htaccess est la commodité. Vous n'avez pas besoin d'un accès root pour modifier le comportement du serveur web, et les modifications prennent effet immédiatement sans redémarrer le serveur. PrestaShop peut écrire son propre fichier .htaccess depuis le back-office, ce qui signifie que des fonctionnalités comme les URL conviviales, la configuration du serveur de médias et certains paramètres de sécurité fonctionnent directement.

L'inconvénient est la performance. Chaque requête oblige Apache à rechercher et analyser les fichiers .htaccess dans chaque répertoire depuis la racine du document jusqu'au répertoire du fichier demandé. Pour une requête PrestaShop typique, Apache pourrait vérifier .htaccess dans /, /var, /var/www, /var/www/html et plus encore. Cela ajoute des opérations d'entrée/sortie disque et du temps de traitement à chaque requête. Pour un site traitant des centaines de requêtes par seconde, cette surcharge est mesurable.

Si vous avez un accès root à la configuration Apache, vous pouvez déplacer toutes les directives .htaccess dans la configuration VirtualHost et désactiver le traitement .htaccess avec AllowOverride None. Cela élimine la surcharge par requête tout en conservant la même fonctionnalité. Cependant, les modifications nécessitent alors un rechargement d'Apache pour prendre effet.

Configuration Nginx

Nginx ne prend pas en charge les fichiers .htaccess. Toute la configuration réside dans les fichiers de configuration des blocs serveur, typiquement sous /etc/nginx/sites-available/ ou /etc/nginx/conf.d/. Chaque règle de réécriture d'URL, directive de contrôle d'accès et en-tête de cache doit être défini dans ces fichiers.

Cela signifie que lorsque vous configurez PrestaShop sur Nginx, vous devez traduire manuellement les règles .htaccess de PrestaShop dans la syntaxe de configuration Nginx. Les règles de réécriture sont fondamentalement différentes entre les deux serveurs. Apache utilise RewriteRule avec des motifs regex et des flags comme [L,R=301], tandis que Nginx utilise des blocs location avec try_files, rewrite et des directives return.

L'avantage de la configuration centralisée est la performance (pas de scan de fichiers par requête) et la clarté (toutes les règles au même endroit). L'inconvénient est que PrestaShop ne peut pas générer la configuration Nginx pour vous. Vous devez l'écrire et la maintenir vous-même, et toute modification nécessite l'exécution de nginx -t pour tester la syntaxe et systemctl reload nginx pour l'appliquer.

Intégration PHP

Les deux serveurs web doivent exécuter du code PHP pour générer les pages PrestaShop. La méthode d'intégration PHP affecte les performances, la stabilité et la gestion des ressources.

Apache avec mod_php

L'approche traditionnelle est Apache avec mod_php, où PHP s'exécute en tant que module à l'intérieur de chaque processus Apache. C'est simple à configurer et il n'y a aucune surcharge de communication inter-processus car PHP s'exécute dans le même processus qui gère la requête HTTP. Cependant, chaque processus worker Apache porte l'environnement d'exécution PHP complet en mémoire, même lors de la diffusion de fichiers statiques comme des images ou du CSS. Cela gaspille de la mémoire car la majorité des requêtes vers une boutique PrestaShop concernent des ressources statiques, pas des pages PHP.

Apache ou Nginx avec PHP-FPM

PHP-FPM (FastCGI Process Manager) exécute PHP en tant que pool de processus séparé. Le serveur web communique avec PHP-FPM via un socket Unix ou une connexion TCP en utilisant le protocole FastCGI. Lorsqu'une requête nécessite un traitement PHP, le serveur web la transmet à PHP-FPM. Une fois le traitement PHP terminé, PHP-FPM renvoie le résultat au serveur web, qui l'envoie au client.

Avec PHP-FPM, les processus du serveur web qui gèrent les fichiers statiques ne portent pas l'environnement d'exécution PHP, ce qui économise une quantité significative de mémoire. PHP-FPM offre également sa propre gestion de processus avec des fonctionnalités comme le dimensionnement dynamique du pool, le journal des requêtes lentes (journalisation lorsqu'une requête dépasse un seuil de temps) et la possibilité d'exécuter simultanément plusieurs versions de PHP pour différents sites.

Nginx utilise exclusivement PHP-FPM car son architecture événementielle est incompatible avec l'intégration embarquée de PHP. Apache peut utiliser PHP-FPM via mod_proxy_fcgi. Dans les déploiements modernes, PHP-FPM est l'approche recommandée pour les deux serveurs.

Configuration PHP-FPM pour PrestaShop

Quel que soit le serveur web choisi, la configuration de PHP-FPM affecte significativement les performances de PrestaShop. Les paramètres clés comprennent :

pm = dynamic est généralement le meilleur mode de gestion de processus. Il démarre un nombre de base de workers et en lance davantage sous charge, jusqu'à un maximum configuré. Cela équilibre l'utilisation mémoire et la réactivité.

pm.max_children détermine le nombre maximum de processus PHP. Chaque requête PrestaShop utilise typiquement 30 à 80 Mo de mémoire. Divisez donc votre RAM disponible (moins les besoins du serveur web et du système d'exploitation) par 80 pour obtenir un maximum conservateur. Pour un serveur avec 4 Go de RAM utilisable, 50 children est un point de départ raisonnable.

pm.max_requests = 500 recycle chaque worker après 500 requêtes, empêchant l'accumulation de fuites mémoire. Les modules PrestaShop ont occasionnellement des fuites mémoire mineures, et ce paramètre empêche qu'elles deviennent un problème.

Diffusion de fichiers statiques

Une boutique PrestaShop sert de grandes quantités de fichiers statiques : images produits, feuilles de style CSS, fichiers JavaScript, polices et fichiers média téléchargés. Les performances de diffusion de fichiers statiques affectent directement les temps de chargement des pages et l'utilisation des ressources serveur.

Performances d'Apache pour les fichiers statiques

Apache sert les fichiers statiques via ses processus workers. Chaque requête de fichier statique occupe un worker pendant la durée du transfert. Pour les petits fichiers (CSS, JS, petites images), c'est rapide. Pour les fichiers volumineux ou les connexions client lentes, le worker est occupé plus longtemps. Avec mod_php chargé, chaque worker porte une surcharge mémoire PHP inutile même pour les requêtes statiques.

Apache prend en charge sendfile, qui permet au noyau de transférer les fichiers directement du disque vers le socket réseau sans copier les données à travers l'espace utilisateur. Cette fonctionnalité est activée par défaut et aide pour les transferts de gros fichiers. Apache prend également en charge la négociation de contenu, les plages d'octets et les requêtes conditionnelles (If-Modified-Since) nativement.

Performances de Nginx pour les fichiers statiques

Nginx excelle dans la diffusion de fichiers statiques car son modèle événementiel peut gérer des milliers de transferts de fichiers simultanés sans augmenter proportionnellement l'utilisation des ressources. Un seul processus worker Nginx peut servir des centaines de requêtes de fichiers statiques simultanées. Combiné à l'utilisation efficace par Nginx de l'appel système sendfile et à son support intégré du cache de fichiers ouverts (mise en cache des descripteurs de fichiers pour les fichiers fréquemment accédés), la diffusion de fichiers statiques est remarquablement rapide.

Pour les boutiques PrestaShop avec de nombreuses images produits (ce qui est le cas de la plupart des boutiques), l'avantage de Nginx en matière de fichiers statiques est significatif. Les pages produits avec 5 à 10 images, plus les fichiers CSS, JavaScript et de polices, génèrent 20 à 30 requêtes de fichiers statiques par chargement de page. Sous fort trafic, Nginx gère ces requêtes avec considérablement moins de ressources qu'Apache.

Terminaison SSL/TLS

Chaque boutique PrestaShop devrait fonctionner en HTTPS, et le serveur web gère le chiffrement et le déchiffrement SSL/TLS (terminaison). Les deux serveurs supportent bien le TLS moderne, mais il y a des différences de configuration et de performances.

Apache configure SSL via mod_ssl, avec des directives comme SSLEngine on, SSLCertificateFile et SSLProtocol dans le bloc VirtualHost. L'agrafage OCSP, la mise en cache de session et la sélection des suites de chiffrement sont tous configurables.

Nginx configure SSL dans le bloc serveur avec des directives comme ssl_certificate, ssl_protocols et ssl_ciphers. Nginx prend également en charge l'agrafage OCSP et la mise en cache de session, et sa configuration tend à être plus concise.

En termes de performances, la poignée de main TLS est gourmande en CPU en raison du chiffrement asymétrique impliqué. La capacité de Nginx à gérer de nombreuses connexions simultanées avec peu de processus workers signifie qu'il peut traiter plus de poignées de main TLS par seconde avec moins de mémoire. Pour les boutiques qui reçoivent de grandes vagues de nouveaux visiteurs (lors d'une promotion, par exemple), l'avantage de performances TLS de Nginx peut éviter la mise en file d'attente des connexions.

Reverse proxy et répartition de charge

Pour les boutiques PrestaShop à fort trafic, une architecture de reverse proxy sépare les responsabilités et améliore la scalabilité. La configuration la plus courante utilise Nginx comme reverse proxy devant soit Apache, soit une autre instance Nginx exécutant PHP-FPM.

Nginx comme reverse proxy pour Apache

Cette configuration hybride combine les forces des deux serveurs. Nginx se place en façade, gère toutes les connexions entrantes, sert les fichiers statiques directement, gère la terminaison SSL et ne transmet que les requêtes PHP à Apache. Apache gère le traitement PHP, et comme il ne reçoit que des requêtes PHP (pas de fichiers statiques), il a besoin de beaucoup moins de processus workers.

Cette architecture vous donne l'efficacité de gestion des connexions et les performances des fichiers statiques de Nginx tout en préservant le support .htaccess d'Apache pour les règles de réécriture générées par PrestaShop. C'est un chemin de migration courant pour les boutiques qui veulent les performances de Nginx sans réécrire toute leur configuration Apache.

La configuration du proxy Nginx utilise la directive proxy_pass pour transmettre les requêtes à Apache, fonctionnant typiquement sur un port non standard comme 8080. Les fichiers statiques sont servis directement par Nginx via un bloc location qui correspond aux extensions de fichiers comme .jpg, .css, .js et .png.

Configuration Nginx complète

Pour des performances maximales, Nginx gère tout : fichiers statiques et requêtes PHP (via PHP-FPM). Il n'y a pas d'Apache dans la pile. Cela élimine la communication inter-processus entre Nginx et Apache et supprime la surcharge mémoire liée à l'exécution de deux serveurs web. Cependant, cela nécessite de créer et maintenir manuellement la configuration Nginx pour la réécriture d'URL de PrestaShop, ce qui représente plus de travail initial.

Configuration Nginx recommandée pour PrestaShop

Une configuration Nginx de production pour PrestaShop doit gérer les URL conviviales, l'accès au panneau d'administration, la mise en cache des fichiers statiques, la communication PHP-FPM et la sécurité. Les éléments clés comprennent un bloc serveur écoutant sur les ports 80 et 443, un bloc de configuration SSL avec vos certificats, une directive root pointant vers votre installation PrestaShop et plusieurs blocs location.

Le bloc location principal utilise try_files $uri $uri/ /index.php?$args pour gérer les URL conviviales de PrestaShop. Il essaie d'abord de servir la requête comme fichier statique, puis comme répertoire, et enfin la passe au dispatcher PrestaShop via index.php.

Un bloc location correspondant à ~ \.php$ transmet les requêtes PHP à PHP-FPM via fastcgi_pass. Il inclut les paramètres FastCGI standard et définit le SCRIPT_FILENAME vers le chemin correct.

Un bloc location pour les ressources statiques définit de longs en-têtes d'expiration du cache et désactive la journalisation d'accès pour réduire les E/S. Les motifs de correspondance comme \.(jpg|jpeg|gif|png|svg|css|js|ico|woff|woff2|ttf|eot)$ capturent les types de fichiers statiques courants.

Les blocs location liés à la sécurité interdisent l'accès aux fichiers et répertoires sensibles : .htaccess, .git, config/ (sauf config/xml/ dont PrestaShop a besoin), vendor/, app/config/ et d'autres répertoires qui ne devraient jamais être accessibles via le web.

Configuration Apache recommandée pour PrestaShop

Apache avec le MPM Event et PHP-FPM offre le meilleur hébergement PrestaShop basé sur Apache. La configuration VirtualHost devrait activer les modules rewrite, headers, expires, deflate et proxy_fcgi.

Le DocumentRoot pointe vers votre installation PrestaShop. AllowOverride All active le traitement .htaccess, nécessaire sauf si vous déplacez toutes les règles de réécriture de PrestaShop dans la configuration VirtualHost.

L'intégration PHP-FPM utilise soit SetHandler soit ProxyPassMatch pour transmettre les requêtes .php au socket PHP-FPM. L'approche SetHandler avec proxy:unix:/run/php/php-fpm.sock|fcgi://localhost est plus simple et recommandée pour la plupart des configurations.

Activez la compression gzip avec mod_deflate pour les types de contenu textuels : HTML, CSS, JavaScript, JSON, XML et SVG. Activez le cache navigateur avec mod_expires en définissant des délais d'expiration longs pour les ressources statiques et des délais plus courts pour le HTML.

Benchmarks de performance et différences en conditions réelles

Les chiffres bruts de benchmark varient énormément selon le matériel, la configuration, la version PHP et la version PrestaShop. Plutôt que de présenter des chiffres spécifiques qui seraient trompeurs hors contexte, voici les tendances qui émergent systématiquement dans les benchmarks d'hébergement PrestaShop.

Pour la diffusion de fichiers statiques, Nginx est systématiquement 2 à 3 fois plus rapide qu'Apache et utilise significativement moins de mémoire. Cet écart se creuse à mesure que la concurrence augmente. À 100 connexions simultanées, la différence peut être de 20 %. À 1 000 connexions simultanées, Nginx peut utiliser 10 fois moins de mémoire.

Pour le traitement des requêtes PHP, le serveur web n'est pas le goulot d'étranglement. Le temps de traitement PHP-FPM domine le cycle de vie de la requête, et les deux serveurs web ajoutent une surcharge négligeable par rapport au temps que PHP passe à exécuter le code PrestaShop, interroger la base de données et rendre les templates. La différence de traitement des requêtes PHP entre Apache avec PHP-FPM et Nginx avec PHP-FPM est typiquement inférieure à 5 %, ce qui est dans la marge d'erreur de mesure pour la plupart des boutiques.

Pour les charges de travail mixtes (le scénario réaliste), l'avantage de Nginx provient de sa gestion efficace des fichiers statiques parallèlement aux requêtes PHP. Un chargement de page génère une requête PHP et 20 à 30 requêtes de fichiers statiques. Nginx gère les 20 à 30 requêtes statiques avec une consommation de ressources triviale, tandis qu'Apache assigne un thread worker à chacune. Sous fort trafic, cette différence de consommation de ressources signifie que Nginx peut maintenir une concurrence plus élevée avant que les performances ne se dégradent.

La conclusion pratique est que pour les boutiques avec moins de 50 visiteurs simultanés, le choix du serveur web ne fait presque aucune différence perceptible. Pour les boutiques approchant ou dépassant 100 visiteurs simultanés, les avantages architecturaux de Nginx deviennent significatifs.

Guide de migration : Apache vers Nginx

Migrer une boutique PrestaShop existante d'Apache vers Nginx implique la traduction de la configuration, des tests approfondis et le basculement.

Étape 1 : Traduire les règles .htaccess

Ouvrez votre fichier .htaccess PrestaShop et identifiez toutes les règles de réécriture actives. La section critique est la réécriture des URL conviviales, qui commence typiquement par RewriteCond %{REQUEST_FILENAME} !-f et RewriteRule .* - [E=REWRITEBASE:/]. Celles-ci se traduisent par la directive Nginx try_files mentionnée dans la section de configuration ci-dessus.

Les réécritures de serveur de médias, la gestion des préfixes de langue et toutes les redirections personnalisées doivent également être traduites. Chaque paire Apache RewriteRule et RewriteCond doit être convertie en la directive Nginx location, rewrite ou return équivalente.

Étape 2 : Configurer Nginx à côté d'Apache

Installez Nginx et configurez-le pour écouter sur un port différent (comme 8080) pendant qu'Apache continue de fonctionner sur le port 80. Cela vous permet de tester la configuration Nginx sans affecter le site en production. Pointez Nginx vers la même racine de document qu'Apache afin qu'il serve les mêmes fichiers.

Étape 3 : Tout tester

Accédez au site via le port de Nginx et testez chaque aspect : la page d'accueil, les pages de catégories, les pages produits, le panier, le processus de commande, le panneau d'administration, les URL conviviales, le chargement des images et le routage d'URL multilingue. Portez une attention particulière aux motifs d'URL impliquant des caractères spéciaux ou des paramètres de requête.

Étape 4 : Basculer

Une fois les tests terminés, arrêtez Apache et reconfigurez Nginx pour écouter sur les ports 80 et 443. Rechargez Nginx et vérifiez que le site en production fonctionne correctement. Conservez la configuration Apache intacte pendant quelques jours au cas où vous auriez besoin de revenir en arrière.

Problèmes de migration courants

Le problème le plus courant est l'absence de règles de réécriture pour le routage d'URL multilingue de PrestaShop. Si votre boutique utilise plusieurs langues avec des codes de langue dans l'URL (comme /en/, /de/, /fr/), assurez-vous que la configuration Nginx gère correctement ces préfixes.

Un autre problème courant concerne les limites de taille de téléchargement de fichiers. Apache utilise LimitRequestBody tandis que Nginx utilise client_max_body_size. Si vous importez des produits avec de grandes images, définissez client_max_body_size à au moins 20M.

Les requêtes AJAX du panneau d'administration qui dépendent de la réécriture .htaccess peuvent échouer si les règles Nginx correspondantes sont manquantes. Testez le panneau d'administration de manière approfondie, y compris l'édition de produits, la gestion des commandes et la configuration des modules.

Lequel devriez-vous choisir

Choisissez Apache si vous êtes sur un hébergement mutualisé où vous ne contrôlez pas le serveur web, si vous dépendez fortement de .htaccess pour la configuration (règles générées par des modules, plugins de sécurité), ou si vous n'êtes pas à l'aise pour écrire et maintenir des fichiers de configuration Nginx. Apache avec le MPM Event et PHP-FPM est une configuration solide et bien supportée pour les boutiques PrestaShop à trafic modéré.

Choisissez Nginx si vous avez un accès root à votre serveur, si votre boutique gère un trafic significatif (des centaines ou milliers de visiteurs simultanés), si vous voulez la consommation de ressources la plus faible possible pour un niveau de trafic donné, ou si vous configurez un nouveau serveur et préférez les avantages à long terme de l'architecture de Nginx. L'effort de configuration initial est un coût unique qui se rentabilise en performances et en efficacité des ressources.

Choisissez l'approche Nginx reverse proxy devant Apache si vous voulez les performances de Nginx pour les fichiers statiques et la gestion des connexions mais avez besoin du support .htaccess d'Apache pour la compatibilité avec les modules PrestaShop qui génèrent ou dépendent de règles .htaccess.

Pour la plupart des nouvelles installations PrestaShop sur un VPS ou un serveur dédié, Nginx avec PHP-FPM est le choix recommandé. La configuration est bien documentée, les avantages de performance sont réels, et la simplicité opérationnelle d'une pile serveur web unique réduit la charge de maintenance. Pour les boutiques existantes sur Apache qui fonctionnent de manière satisfaisante, la migration vers Nginx est une optimisation intéressante mais pas une nécessité urgente, sauf si vous atteignez les limites de performance.