Pourquoi votre site en hébergement mutualisé est lent : limites LVE, erreurs 503 et PHP X-Ray

Votre site est devenu poussif, ou vos visiteurs voient une erreur 503 Resource Limit Reached. Le premier réflexe est d'accuser le serveur ou de passer à une offre supérieure. Sur un hébergement mutualisé, la cause se trouve généralement dans votre application, et vous pouvez la trouver vous-même en quelques minutes grâce aux outils déjà présents dans cPanel.

Votre compte fonctionne dans son propre conteneur

Chaque compte mutualisé et revendeur WebGee fonctionne dans son propre Lightweight Virtual Environment (LVE), un conteneur CloudLinux doté de limites de ressources fixes. Si un compte exécute un script qui s'emballe ou subit une attaque, il est bridé ou voit ses processus interrompus, et tous les autres comptes continuent de fonctionner normalement. Ces limites existent pour que le problème d'un autre ne devienne jamais le vôtre.

Sauf mention contraire dans votre offre, chaque compte dispose de :

• CPU : 1 cœur
• Mémoire : 1 GB
• Entry processes : 30 simultanés

Retrouvez l'explication complète dans CloudLinux et les limites LVE expliqués.

Associer le symptôme à la limite

Chaque limite se comporte différemment lorsqu'elle est atteinte, ce qui vous indique où chercher :

• CPU : le site ralentit, mais les requêtes aboutissent quand même.
• I/O : le site ralentit, en particulier pour tout ce qui sollicite fortement le disque.
• Entry processes (EP) : une erreur 503, car les requêtes sont purement et simplement interrompues.
• Mémoire physique (PMEM) : une erreur 503, ou l'arrêt du processus.

Les limites CPU et I/O dégradent votre site ; les limites d'entry processes et de mémoire le rendent inutilisable. Un site poussif ne bute pas sur la même limite qu'un site qui renvoie des erreurs 503.

Pourquoi les sites lents manquent d'entry processes

Un entry process est une requête en cours de traitement au sein de votre compte. La limite porte sur le nombre de requêtes pouvant s'exécuter au même instant, et non par heure ni par visiteur. Une requête PHP se termine généralement en une fraction de seconde, et son emplacement se libère dès qu'elle s'achève.

Le piège, c'est que plus chaque requête dure longtemps, moins il faut de visiteurs pour atteindre la limite. Une page qui met 5 secondes occupe son emplacement 25 fois plus longtemps qu'une page qui en met 200 ms. Dès que les requêtes commencent à s'accumuler, les pages ralentissent encore davantage et occupent leurs emplacements plus longtemps. Ce cercle vicieux explique pourquoi les sites tombent souvent d'un coup plutôt que progressivement.

Les requêtes qui dépassent la limite sont interrompues par le noyau avec SIGKILL, et le visiteur voit l'erreur 503. Les déclencheurs habituels sont des traitements longs :

• Une tâche cron qui dure plusieurs minutes et s'exécute toutes les minutes
• WP-Cron qui se déclenche au chargement des pages
• Une extension qui effectue un appel lent à une API externe à chaque requête
• Une requête de base de données sans index

Plus de détails dans Qu'est-ce qu'un entry process.

Identifier la limite atteinte

Commencez par cPanel → Resource Usage. Cet outil indique quelle limite a été atteinte, à quel moment, et ce qui s'exécutait à cet instant.

1. Dans cPanel, ouvrez Resource Usage.
2. Sélectionnez la période couvrant la lenteur, les erreurs 503 ou l'e-mail d'alerte.
3. Vérifiez quelle limite a été atteinte : CPU, I/O, entry processes ou mémoire.
4. Ouvrez l'instantané (snapshot) correspondant à ce moment. Il liste les processus responsables.

C'est l'instantané qui transforme un symptôme en cause. Si les dépassements se concentrent à une heure précise, consultez ensuite cPanel → Cron Jobs, car une tâche lourde programmée à intervalle court est un coupable fréquent.

Consultez Vous avez reçu une alerte d'utilisation des ressources et Corriger une erreur 503 Resource Limit Reached pour la procédure complète.

Tracer les requêtes lentes avec PHP X-Ray

Resource Usage vous dit quelle limite est en cause ; PHP X-Ray vous dit où passe le temps au sein d'une requête. Il trace de vraies requêtes et les décompose une à une, pour que vous n'ayez plus à deviner si le problème vient d'une extension, d'une requête de base de données ou d'un appel externe. Il est disponible sur les hébergements mutualisé, revendeur et Premium.

1. Dans cPanel, ouvrez X-Ray.
2. Sélectionnez le domaine ou le sous-domaine à tracer.
3. Saisissez votre propre adresse IP, réglez le nombre de requêtes à collecter entre 10 et 20, et choisissez une durée suffisante pour reproduire la lenteur.
4. Lancez le traçage, puis consultez la page lente plusieurs fois dans votre navigateur.
5. Ouvrez la trace collectée une fois la colonne Collected Requests remplie.

Recherchez les éléments suivants, classés à peu près selon la fréquence à laquelle ils sont en cause :

• Une requête de base de données lente répétée de nombreuses fois, généralement une extension qui interroge la base dans une boucle. La mise en cache d'objets règle souvent le problème d'emblée.
• Un appel HTTP externe lent, par exemple une extension qui contacte un serveur de licences ou une API. La page ne peut pas se terminer tant que l'appel n'a pas répondu.
• Une extension qui monopolise le temps total. Désactivez-la et relancez une trace pour confirmer.

Des captures d'écran étape par étape sont disponibles dans Trouver ce qui ralentit votre site.

Ne confondez pas le memory_limit de PHP avec la limite de votre compte

memory_limit plafonne la quantité de mémoire qu'un seul script PHP peut allouer. Vous la modifiez dans cPanel → Select PHP Version → Options (voir Modifier votre version et vos paramètres PHP). L'augmenter est raisonnable pour des imports volumineux, le traitement d'images lors de gros envois, une boutique WooCommerce au catalogue important ou une application dont la documentation exige une valeur plus élevée.

Cela n'augmente pas la limite de mémoire de votre compte. Celle-ci est fixée par votre offre, et c'est elle qui provoque les erreurs 503. Régler memory_limit au-delà de l'allocation de votre compte ne sert à rien, car le script est de toute façon interrompu à la limite du compte.

Un chargement de page WordPress classique tient largement dans 128 à 256 MB. Si votre page d'accueil a besoin de 1 GB, quelque chose charge bien plus que nécessaire : une extension qui interroge la base sans limite, une boucle sans fin, ou un traitement d'images à chaque requête au lieu d'une seule fois lors de l'envoi. Tracez-le avec X-Ray avant d'augmenter quoi que ce soit.

Pour vérifier la valeur réellement appliquée, créez un fichier PHP contenant <?php echo ini_get('memory_limit');, chargez-le, puis supprimez-le. Avec Bolt-Cache, le PHP Selector est ignoré et la valeur provient de .user.ini. Pour en savoir plus, consultez Comprendre les limites de mémoire PHP.

Réduire votre consommation

Corrigez d'abord l'application. Ces étapes, dans cet ordre, règlent la plupart des cas :

1. Activez la mise en cache. Une page en cache n'atteint jamais PHP et ne devient donc jamais un entry process. Commencez par LiteSpeed Cache, puis ajoutez la mise en cache d'objets Redis pour le trafic des utilisateurs connectés et l'espace d'administration.
2. Auditez vos extensions. Désactivez-les toutes, patientez quelques minutes, puis réactivez-les une par une en surveillant Resource Usage.
3. Corrigez vos tâches cron. WP-Cron s'exécute au chargement des pages, ce qui est le mauvais comportement en cas de forte charge. Remplacez WP-Cron par une véritable tâche cron, et allongez l'intervalle de toute autre tâche lourde.
4. Recherchez un trafic anormal. Les robots et les scrapers consomment les mêmes ressources que vos clients.
5. Recherchez les logiciels malveillants. Un site compromis gaspille ses ressources à travailler pour quelqu'un d'autre. Analysez votre site à la recherche de logiciels malveillants.

Détecter les problèmes avant vos visiteurs

Site Quality Monitoring, dans cPanel, vérifie la disponibilité d'un domaine toutes les heures et effectue chaque semaine une analyse complète de santé et de performances, à la recherche de liens cassés, de métadonnées manquantes, de pages lentes et de contenu mixte. Cet outil reste désactivé tant que vous n'avez pas créé de projet :

1. Dans cPanel, sélectionnez Site Quality Monitoring.
2. Choisissez le Monitored domain et saisissez une Email Address de notification.
3. Cochez la case de consentement et sélectionnez Create Project.

Utilisez une adresse qui n'est pas hébergée sur le compte surveillé, sinon une alerte d'indisponibilité risque de ne jamais vous parvenir. La surveillance voit ce que voit un visiteur : elle ne peut donc pas vous dire pourquoi une page est lente. Si elle signale des indisponibilités intermittentes, consultez Resource Usage, car la cause tient souvent aux limites de ressources plutôt qu'à une panne.

Les détails de configuration se trouvent dans Site Quality Monitoring.

Quand une montée en gamme est la bonne solution

Ne passez à une offre supérieure qu'après avoir posé un diagnostic. Une montée en gamme relève le plafond sans s'attaquer à ce qui consomme les ressources : une extension qui s'emballe consommera simplement davantage. Si l'instantané de Resource Usage montre un trafic légitime effectuant un travail légitime, les limites peuvent être relevées, et c'est précisément la vocation des offres Elastic Cloud. Ouvrez un ticket en joignant vos chiffres de Resource Usage, et WebGee vous conseillera.