À partir de quand passer à un hébergement dédié pour PrestaShop ?

Vous constatez des temps de chargement allongés sur votre boutique PrestaShop ? Aussi bien sur le front office que sur le back office ? Cela ne provient probablement pas d’un mauvais paramétrage. Ce serait plutôt du fait que votre infrastructure n’a pas évolué au rythme de votre activité. En effet, un hébergement mutualisé peut devenir un frein lorsque le trafic s’intensifie. Nous allons donc vous aider à reconnaître le moment où vous avez besoin de passer à un hébergement dédié pour PrestaShop.

Les premiers signaux d’alerte à surveiller sur un hébergement mutualisé

Les premiers signes prennent différentes formes :

• Le back-office et le front-office commencent à répondre lentement sur certaines plages horaires
• Les imports de catalogue via CSV s’interrompent en cours d’exécution
• Les commandes mettent plusieurs secondes à s’afficher

Ce sont les premiers signaux qui indiquent que les ressources allouées ne couvrent plus la charge effective de la boutique. Mais d’autres problèmes indiquent qu’un hébergement mutualisé pour PrestaShop n’est plus suffisant.

Les timeouts PHP sont souvent le symptôme le plus visible. Lorsque le serveur coupe l’exécution d’un script au bout de 30 ou 60 secondes, c’est généralement parce que la mémoire disponible est saturée ou que le processus attend des ressources CPU déjà mobilisées par d’autres sites hébergés sur la même machine. Sur un hébergement mutualisé, vous ne contrôlez malheureusement ni l’allocation mémoire ni la priorité d’exécution.

Les cron jobs sont aussi un indice indiquant qu’un changement d’hébergement pour PrestaShop s’impose. Ce sont des tâches planifiées exécutées automatiquement par le serveur à intervalles définis, sans intervention manuelle. Il peut s’agir d’une mise à jour des stocks, d’une relance des paniers abandonnés, d’une synchronisation avec un ERP, d’une génération de rapports… Sur un environnement partagé, ces tâches s’exécutent dans une file d’attente commune et peuvent être retardées, tronquées ou simplement ignorées si les ressources sont indisponibles au moment où elles se déclenchent.

Un autre indicateur fiable est la dégradation des temps de réponse en période de trafic concurrent. Si le Time to First Byte de votre boutique s’allonge sensiblement lors des pics, ce n’est pas un problème de cache, mais un problème de contention au niveau de l’infrastructure. Nous avons déjà évoqué le sujet du TTFB et de son impact dans l’un de nos articles où nous parlons des moyens de savoir si son hébergement est performant.

Charge réelle et ressources allouées : le point de rupture

Un hébergement mutualisé concentre plusieurs centaines de sites qui se partagent les mêmes ressources physiques. L’hébergeur parie sur le fait que tous ces sites ne sollicitent pas le serveur au même moment. Tant que votre boutique génère un trafic modeste et des opérations légères, ce modèle fonctionne. Dès que ce n’est plus le cas, vous subissez les conséquences de la charge des voisins autant que la vôtre.

Qu’est-ce que PrestaShop consomme ?

PrestaShop est un CMS gourmand par nature. Chaque page produit déclenche plusieurs requêtes SQL, des appels de hooks, du rendu de templates Smarty ou TWIG et potentiellement des appels à des modules tiers. Sur un catalogue de 500 SKU avec des combinaisons, une session utilisateur peut générer plusieurs dizaines de requêtes. Multipliez par 20 visiteurs simultanés et vous comprenez pourquoi la mémoire vive et les I/O disque deviennent rapidement des goulots d’étranglement.

La limite d’inodes est un autre point de friction en fonction du système de fichier (FS) utilisé. PrestaShop génère un volume important de fichiers (cache Smarty, images déclinées en plusieurs formats, logs, fichiers de session…). Sur certaines offres mutualisées, le quota d’inodes est atteint avant le quota de stockage, ce qui provoque des erreurs pénibles à diagnostiquer.

Y’a-t-il des seuils à partir desquels le serveur mutualisé ne suffit plus ?

Il n’y a pas de seuil défini à ne pas dépasser pour la simple et bonne raison tout dépend des besoins de votre site PrestaShop (trafic, modules, catalogue, etc…) et de ce que votre serveur vous accorde. Ce qui compte donc, c’est le rapport entre la charge générée par votre boutique et les ressources allouées à votre hébergement mutualisé, pas vraiment celles annoncées dans la fiche de l’offre de votre hébergeur. En effet, certains clients pensent bénéficier des 48 CPU du serveur physique sur lequel ils sont. Sauf qu’en mutualisé, vous partagez ses 48 CPU avec probablement plus d’une centaine de sites. Au final, vous vous retrouvez avec moins d’un demi CPU pour votre site.

VPS ou serveur dédié : lequel privilégier pour un hébergement PrestaShop ?

La distinction entre VPS et serveur dédié est la plupart du temps présentée comme une question de budget. Mais connaissez-vous la différence ? C’est avant tout une question d’isolation des ressources. Sur un VPS, vous disposez d’une partition virtuelle d’un serveur physique. Les ressources CPU et RAM vous sont allouées, mais le matériel reste partagé. Sur un serveur dédié, vous êtes seul sur la machine, aucun autre client ne peut impacter vos performances.

Un VPS bien dimensionné peut couvrir une large gamme de boutiques PrestaShop. À partir de 4 vCPU et 8 Go de RAM, avec un stockage NVMe et un environnement correctement configuré (PHP-FPM, OPcache, Redis pour les sessions), une boutique de taille intermédiaire tourne sans difficulté. Le VPS convient tant que la charge reste prévisible, que les pics sont absorbables et que vous n’avez pas de contraintes fortes sur les I/O disque.

Votre hébergeur est garant que les ressources allouées à votre VM soient réellement disponibles physiquement.

Au final, quand passer à un hébergement dédié pour PrestaShop ?

Le passage à un hébergement dédié à PrestaShop s’impose lorsque la contention sur votre VPS devient récurrente, ou lorsque les exigences techniques dépassent ce que la virtualisation permet d’offrir. Des opérations intensives en I/O disque, comme la génération massive de fichiers PDF, les imports de catalogues volumineux ou les exports vers un ERP, sollicitent le stockage de façon soutenue. Sur un hyperviseur partagé, ces opérations entrent en compétition avec les charges des autres VPS hébergés sur la même machine physique.

La fréquence CPU est un autre critère que vous devez regarder. Sur un serveur dédié, vous accédez aux cycles processeurs sans couche de virtualisation. Pour des opérations de calcul intensif, le gain serait mesurable. Les boutiques PrestaShop qui gèrent des règles de prix complexes, des modules de personnalisation produit ou des traitements batch réguliers ont un certain bénéfice à tirer d’un hébergement dédié.

Les avantages à héberger PrestaShop sur un serveur dédié

PHP-FPM et gestion des workers

PHP-FPM permet de gérer un pool de processus PHP indépendants, dimensionné en fonction de la charge attendue. Sur un hébergement mutualisé, ce paramétrage vous échappe complètement. Sur un dédié ou sur un VPS, vous définissez le nombre de workers, la mémoire maximale par processus et la politique de recyclage. Pour PrestaShop, qui génère des scripts parfois lourds en mémoire, cela change directement les temps de réponse sous charge.

L’activation d’OPcache avec des paramètres adaptés au volume de fichiers PHP de PrestaShop réduit significativement la charge CPU. Sans OPcache, chaque requête recompile les fichiers PHP.

Tuning MySQL/MariaDB

PrestaShop est très sollicitant pour la base de données. Le paramétrage par défaut de MySQL ne convient pas à une boutique active. L’ajustement de l’innodb_buffer_pool_size, du query_cache ou du nombre de connexions simultanées autorisées a un impact sur la latence des pages et la stabilité du back-office en heure de pointe.

Sur un hébergement dédié, il est possible d’isoler le service MySQL sur un disque dédié ou de déporter la base sur un serveur distinct. Cela supprime toute contention entre les I/O applicatifs et les I/O base de données.

Tâches planifiées et stabilité des traitements batch

Les cron jobs de PrestaShop comme la synchronisation des stocks, la génération des rapports ou les exports comptables s’exécutent dans un environnement où les ressources ne sont disputées par personne d’autre. Avec un hébergement dédié, ces traitements s’exécutent dans des délais agréables.

Faire infogérer son hébergement PrestaShop

L’infogérance consiste à déléguer l’administration de votre serveur à l’équipe technique de votre hébergeur. C’est l’équipe technique de l’hébergeur qui configure l’environnement et applique les mises à jour système et de sécurité. Elle effectue un monitoring 24h/24 pour surveiller les ressources et intervient en cas d’incident. Pour éviter les indisponibilités de votre site ou de votre application, c’est une offre particulièrement pertinente. En effet, une équipe technique est dédiée au rétablissement de votre activité en cas de panne. C’est ce que nous proposons chez Gladhost.