Hébergement PrestaShop sur VPS OVH : configuration de production Nginx et PHP-FPM

Un e-commerçant qui passe de 10 à 50 commandes par jour franchit un seuil invisible sur le papier, mais très concret côté serveur. Ce n'est pas une question de volume de ventes : c'est une question de requêtes PHP simultanées, de connexions MySQL ouvertes en parallèle et de cycles CPU partagés avec des dizaines d'autres sites sur le même hôte. Cet article détaille pourquoi l'hébergement mutualisé craque à ce niveau de trafic, et comment dimensionner correctement un VPS NVMe OVH avec Nginx, PHP-FPM et MariaDB pour tenir la charge sans y laisser des heures de debugging le soir.

Pourquoi l'hébergement mutualisé sature dès 50 commandes par jour

Un hébergement mutualisé repose sur un principe simple : plusieurs centaines de sites partagent le même serveur physique, le même processeur, la même bande passante disque. Tant que le trafic reste faible, la mutualisation des ressources fonctionne. Le problème apparaît quand PrestaShop, un CMS particulièrement gourmand en requêtes SQL et en calculs PHP à chaque affichage de page produit, commence à générer plusieurs dizaines de requêtes simultanées.

Concrètement, voici ce qui se passe techniquement quand une boutique PrestaShop dépasse ce seuil sur un mutualisé :

• Limite de processus PHP concurrents : les hébergeurs mutualisés imposent un nombre maximal de processus PHP actifs par compte, souvent entre 4 et 10. Au-delà, les visiteurs supplémentaires attendent en file, ce qui se traduit par des temps de réponse qui grimpent brutalement.
• CPU throttlé : le processeur est partagé selon des quotas invisibles. Un pic de trafic sur un autre site du même serveur peut directement dégrader les temps de réponse de votre boutique, sans qu'aucune alerte ne vous prévienne.
• Base de données mutualisée : MySQL tourne en mode partagé, avec un buffer pool minuscule réparti entre des centaines de bases. Les requêtes de recherche produit, de gestion du panier et de calcul des promotions deviennent lentes dès que le cache mémoire ne suffit plus.
• I/O disque partagé : même sur un hébergeur annonçant du SSD, l'accès disque reste mutualisé. Les écritures de logs, de sessions et de cache PrestaShop entrent en concurrence avec celles des voisins.

Le résultat mesurable : un temps de génération de page qui passe de 400 ms à plus de 3 secondes aux heures de pointe, une hausse du taux de rebond, et des paniers abandonnés parce que la validation de commande timeout. Ce n'est pas une impression, c'est un phénomène observable dans n'importe quel outil de mesure de performance web.

Sur les audits que nous menons, le motif de migration le plus fréquent n'est jamais « le site est tombé ». C'est toujours la même phrase : « ça rame le vendredi soir, et je ne comprends pas pourquoi ». La réponse est presque toujours la même : le mutualisé n'a jamais été conçu pour absorber des pics de charge PHP-FPM et MySQL simultanés. — CodeMyShop, retour de terrain sur les migrations PrestaShop

Dimensionner un VPS NVMe OVH selon le trafic réel de la boutique

Le passage à un VPS NVMe OVH change radicalement la donne : ressources CPU dédiées ou garanties, stockage NVMe avec des débits d'écriture largement supérieurs au SSD classique, et surtout un contrôle total sur la configuration serveur. Mais dimensionner un VPS ne consiste pas à prendre l'offre la plus chère par précaution. Il s'agit de calculer les ressources réellement nécessaires selon le trafic, le nombre de produits en catalogue et la complexité du thème.

Le tableau suivant donne des ordres de grandeur pour dimensionner un VPS NVMe selon le volume de commandes quotidien, en tenant compte du fait que le trafic de visite est généralement 20 à 40 fois supérieur au nombre de commandes converties :

Ces chiffres supposent un thème PrestaShop standard, sans surcharge de modules tiers exécutant des requêtes lourdes à chaque affichage. Un catalogue volumineux avec des variantes de produits complexes (tailles, couleurs, déclinaisons multiples) consomme davantage de mémoire par requête PHP, ce qui doit être intégré dans le calcul du pool. Une boutique qui vend par exemple des t-shirts déclinés en plusieurs tailles dans sa collection homme génère mécaniquement plus de jointures SQL sur les pages catégorie qu'une boutique à catalogue simple.

Nginx en production : configuration serveur pour PrestaShop

Nginx sert de reverse proxy devant PHP-FPM et gère l'essentiel du trafic statique. Une configuration Nginx mal réglée annule une bonne partie du gain apporté par le passage au VPS NVMe. Voici les points de configuration qui font une différence mesurable en production :

• worker_processes auto associé à worker_connections dimensionné selon le nombre de vCPU réel du VPS, pas selon une valeur copiée d'un tutoriel générique.
• gzip ou brotli activé sur les réponses HTML, CSS et JS, avec un niveau de compression 5 ou 6 pour équilibrer charge CPU et gain de bande passante.
• try_files correctement configuré pour respecter la réécriture d'URL PrestaShop, faute de quoi certaines pages catégorie ou fiche produit renvoient des erreurs 404 après une migration.
• fastcgi_cache ou microcache sur les pages publiques non personnalisées, avec des règles d'exclusion strictes sur les pages panier, compte client et paiement pour éviter de servir du contenu en cache à un client connecté.
• Fichiers statiques servis directement par Nginx (images, CSS, JS) sans passer par PHP-FPM, avec des en-têtes de cache navigateur longs sur les assets versionnés.

Une architecture Nginx bien pensée fonctionne d'ailleurs de la même façon qu'elle soit déployée directement sur le VPS ou conteneurisée. Sur ce point, notre guide Docker Compose pour PrestaShop en production détaille une configuration reproductible qui isole Nginx, PHP-FPM et MariaDB dans des conteneurs distincts, ce qui simplifie considérablement les montées de version.

PHP-FPM optimisé : pools distincts, OPcache et limites mémoire réelles

PHP-FPM est le composant le plus souvent mal configuré sur un VPS PrestaShop. La tentation est de laisser les valeurs par défaut ou de copier une configuration trouvée en ligne sans l'adapter à la RAM réellement disponible. Or un pool PHP-FPM mal dimensionné provoque soit une sous-utilisation du serveur, soit un swap mémoire qui ralentit tout le système.

Le calcul de base est simple : chaque processus PHP-FPM sous PrestaShop consomme en moyenne entre 60 et 120 Mo de RAM selon les modules actifs. Sur un VPS de 8 Go réservant 3 Go au système, à MariaDB et au cache OPcache, il reste environ 5 Go disponibles pour PHP-FPM, ce qui autorise un pm.max_children d'environ 40 à 50, à condition de mesurer la consommation réelle avec un outil de monitoring plutôt que de deviner.

Les réglages qui font la différence concrète en production :

1. Pools PHP-FPM distincts : un pool dédié au front-office public, un pool dédié au back-office administrateur. Cela évite qu'un import massif de produits dans l'administration ne consomme tous les processus disponibles et bloque les visiteurs du site public.
2. pm = dynamic avec un pm.start_servers proche du trafic moyen observé, et un pm.max_spare_servers qui absorbe les pics sans sur-allouer en permanence.
3. OPcache activé et dimensionné : opcache.memory_consumption à 256 Mo minimum pour un catalogue PrestaShop de taille moyenne, opcache.max_accelerated_files relevé au-dessus de 20 000 pour couvrir l'ensemble des fichiers du cœur et des modules, et opcache.validate_timestamps désactivé en production pour éviter une vérification systématique des fichiers à chaque requête (au prix d'un rechargement manuel après déploiement).
4. request_terminate_timeout réglé pour éviter qu'un processus PHP bloqué (souvent lié à un module tiers ou un appel API externe défaillant) ne monopolise un slot du pool indéfiniment.

La limite mémoire théorique annoncée par un fournisseur ne correspond presque jamais à ce qu'on observe en charge réelle. Sur les VPS que nous configurons, nous mesurons systématiquement la consommation par processus PHP-FPM pendant 48 heures avant de figer le pool. C'est la seule méthode fiable, tout calcul purement théorique sous-estime l'impact des modules PrestaShop tiers. — CodeMyShop, note d'exploitation VPS

MariaDB fine-tunée : buffer pool, connexions et requêtes lentes

MariaDB constitue souvent le goulot d'étranglement invisible d'une boutique PrestaShop, car les symptômes apparaissent côté PHP alors que la cause réside dans la base. Le réglage le plus déterminant est l'innodb_buffer_pool_size, qui doit être fixé entre 50 et 70 % de la RAM disponible sur un serveur dédié à la base de données, et proportionnellement moins sur un VPS mutualisant Nginx, PHP-FPM et MariaDB sur la même machine.

Les autres variables à surveiller de près :

• max_connections aligné sur le nombre réel de processus PHP-FPM susceptibles d'ouvrir une connexion simultanée, pour éviter les erreurs de connexions refusées en pic de trafic.
• slow_query_log activé avec un seuil bas (autour de 0,5 seconde) pendant les premières semaines suivant la mise en production, afin d'identifier les requêtes de modules tiers mal indexées.
• query_cache désactivé sur les versions récentes de MariaDB au profit du cache applicatif PrestaShop, plus pertinent pour un catalogue qui change fréquemment.
• innodb_flush_log_at_trx_commit ajusté selon le compromis souhaité entre durabilité stricte des transactions et performance d'écriture, un point à discuter avec la personne qui exploite l'infrastructure plutôt qu'à régler par défaut.

La documentation officielle de MariaDB détaille précisément le comportement de chacune de ces variables et constitue la référence à consulter avant toute modification en production : MariaDB Knowledge Base — InnoDB System Variables.

Architecture complète : de la configuration serveur à la boutique en production

Une fois Nginx, PHP-FPM et MariaDB réglés indépendamment, l'enjeu devient leur cohérence globale. Un pool PHP-FPM trop généreux face à un buffer pool MariaDB sous-dimensionné déplace simplement le goulot d'étranglement d'un composant à l'autre. C'est pourquoi le dimensionnement doit se faire de façon itérative, en observant les métriques réelles sous charge plutôt qu'en appliquant des ratios figés.

Ce travail de calibrage est également celui que nous détaillons de façon plus large dans notre guide complet sur l'hébergement PrestaShop VPS OVH, qui couvre en plus la partie sauvegarde, sécurité réseau et migration depuis un mutualisé. Pour les boutiques qui envisagent une conteneurisation complète de leur stack, le passage par Docker sécurise également les montées de version PHP sans risque de casse en production, comme détaillé dans notre article sur le déploiement Docker VPS sans stress.

Un exemple concret pour illustrer l'impact catalogue : une page produit affichant plusieurs déclinaisons visuelles, comme celle du mug personnalisé The best is yet to come, déclenche une série de requêtes SQL de récupération de stock, de prix et de règles promotionnelles à chaque affichage. Multiplié par plusieurs centaines de visiteurs simultanés, c'est précisément ce type de requête qui sature un buffer pool MariaDB sous-dimensionné, bien avant que le CPU ne montre le moindre signe de tension.

Synthèse et prochaine étape pour votre boutique PrestaShop

Le passage d'un hébergement mutualisé à un VPS NVMe OVH n'est pas une dépense de confort : c'est une réponse technique précise à un problème d'architecture. Les hébergements mutualisés saturent dès 50 commandes par jour parce qu'ils partagent CPU, mémoire et I/O disque entre des centaines de sites, sans possibilité de régler finement PHP-FPM, Nginx ou MariaDB selon le profil réel de votre boutique. Un VPS bien dimensionné, avec des pools PHP-FPM séparés, un OPcache correctement calibré et un buffer pool MariaDB proportionné à la RAM disponible, absorbe une charge largement supérieure pour un coût maîtrisé.

Chaque boutique PrestaShop a néanmoins ses propres particularités : volume de catalogue, complexité des modules installés, saisonnalité du trafic. Un diagnostic chiffré reste la seule façon fiable de savoir où se situe réellement le goulot d'étranglement de votre installation actuelle.

Si vous êtes marchand ou dirigeant d'une boutique PrestaShop et que vous souhaitez un état des lieux précis de votre architecture, Alexandre Carette (#4467) réalise une Note de Mesure personnalisée : un diagnostic technique complet couvrant la performance Core Web Vitals, la conformité SEO technique, la sécurité serveur et l'architecture globale de votre boutique. Une base concrète pour décider, chiffres à l'appui, si votre infrastructure actuelle tient réellement la charge de votre activité.