Hébergement mutualisé : quand des processeurs rapides sont-ils utiles malgré un faible nombre de cœurs ?

Distinguer les cœurs, les threads et le temps CPU

Un cœur physique est une unité de calcul du processeur. Le système d'exploitation, en revanche, considère processeurs logiques en tant qu'unités exécutables : en cas de multithreading simultané, plusieurs d'entre elles peuvent partager les ressources d'un même cœur physique. Leur nombre ne permet donc pas de déterminer directement combien de cœurs indépendants les uns des autres sont disponibles pour un compte d'hébergement.

Dans l'hébergement mutualisé, plusieurs comptes se partagent le matériel d'un serveur. Une formule peut limiter le temps CPU que les processus d'un compte sont autorisés à consommer au cours d'une période donnée. Ceci Budget temps CPU est différent de l'engagement d'utiliser un noyau physique de manière exclusive. Les cgroups Linux constituent une base technique possible pour de telles limites, mais ce n'est pas la seule implémentation possible.

Si le forfait mentionne par exemple „ un vCore “ ou „ 100 % du CPU “, vérifie la définition donnée par le fournisseur. Cette indication peut désigner un budget de temps de calcul sans pour autant réserver en permanence un cœur spécifique. De même, le nombre total de cœurs du serveur hôte ne permet pas de déterminer la quantité de puissance qu'un compte individuel est effectivement autorisé à utiliser simultanément.

La « simultanéité » désigne ici le nombre de requêtes ou de processus pouvant être traités en parallèle. Elle dépend notamment des limites de processus, de la mémoire et du budget CPU disponible. CloudLinux peut utiliser ses propres limites de ressources à cette fin ; pour savoir si un forfait utilise cette technologie et comment elle est configurée, tu dois te renseigner auprès du fournisseur.

La limitation des ressources et l'isolation de sécurité remplissent des fonctions différentes : une limite contrôle la consommation, tandis qu'une isolation vise à restreindre l'accès entre les environnements. La Présentation de CloudLinux Site Isolation et CageFS explique les mécanismes de sécurité correspondants ; cela n'implique pas en soi une attribution spécifique de CPU.

Pourquoi le GHz ne suffit pas à lui seul

La fréquence d'horloge indique le nombre de cycles d'horloge qu'un processeur effectue par seconde. Une fréquence plus élevée peut accélérer les tâches dépendantes du processeur, mais elle ne permet pas à elle seule de déterminer dans quelle mesure un site web en bénéficie. Les différentes architectures de processeurs effectuent des charges de travail variables par cycle d'horloge ; le code du programme lui-même influence également le résultat.

À l'adresse suivante : Performances monocœur Le cache et le comportement de la mémoire jouent également un rôle. Si un processus doit souvent attendre des données, une fréquence plus élevée peut avoir moins d'impact que dans le cas d'un calcul dont les données sont déjà rapidement disponibles. Une comparaison basée uniquement sur les GHz occulte ces différences et ne remplace pas un test de performance spécifique à l'application.

L'AMD EPYC 4564P constitue un exemple de fiche technique succincte : pour ce modèle, AMD indique 16 cœurs, 32 threads, une fréquence de base de 4,5 GHz et une fréquence boost maximale pouvant atteindre 5,7 GHz. Ces informations décrivent le processeur, et non les performances d'une offre d'hébergement spécifique.

Le Boost maximal Il ne s'agit ni d'une valeur constante garantie, ni de la fréquence à laquelle tous les cœurs fonctionnent à tout moment. De même, les données du produit n'indiquent pas à quelle vitesse une formule d'hébergement mutualisé donnée traite une requête WordPress ou PHP. Outre le matériel, la configuration, la charge de travail et les limites de la formule jouent également un rôle à cet égard.

Lorsque les prestataires avec hébergement de processeurs haute fréquence Si vous souhaitez en savoir plus, renseignez-vous sur le modèle précis du processeur et le budget alloué aux ressources. Pour que les comparaisons de performances soient pertinentes, il faut également disposer d’informations sur la version du logiciel, la configuration du serveur, la charge de travail et les conditions de test. Sans ces informations, il est impossible de traduire de manière fiable une valeur en GHz mise en avant en un temps de réponse plus court.

Requêtes PHP et traitement parallèle

Dans le cas d'une requête synchrone typique, un worker PHP traite les différentes étapes de son travail PHP principalement les unes après les autres. Un processeur plus rapide peut réduire cette partie du traitement si celle-ci est effectivement gourmande en ressources. En revanche, si le worker attend principalement une réponse de la base de données ou d'un service externe, l'intérêt d'une puissance de calcul supérieure reste limité pour ce temps d'attente.

La formulation de la recherche PHP monocœur Cela ne signifie donc pas qu'un site web dans son ensemble ne peut utiliser qu'un seul noyau. Plusieurs requêtes peuvent être traitées en parallèle par plusieurs workers ; le serveur web et la base de données peuvent également fonctionner simultanément. Ce qui est déterminant, c'est la quantité de ce travail parallèle que permettent les ressources disponibles et la configuration concernée.

Limite avec PHP-FPM pm.max_children le nombre de requêtes traitées simultanément par un pool. Lorsque cette limite est atteinte, les requêtes supplémentaires ne peuvent pas être traitées immédiatement par un autre worker de ce pool. Cette limite ne donne toutefois aucune indication sur le nombre total de visiteurs pouvant utiliser un site web.

Le Gestion des processus PHP-FPM propose trois modes de fonctionnement : static maintient un nombre fixe de workers. dynamic adapte leur nombre à la demande en fonction de la configuration ; ondemand lance les workers si nécessaire. Le mode de fonctionnement sélectionné détermine donc également à quel moment les processus sont disponibles ou redémarrés.

Un plus grand nombre de workers ne se traduit pas automatiquement par un temps CPU plus important. Ils nécessitent également de la mémoire vive et, en cas d'exécution parallèle, peuvent atteindre ensemble la limite d'un compte. Pour évaluer une hébergement mutualisé CPU Le nombre de workers et le budget en ressources vont donc de pair. Tous les forfaits n'utilisent pas PHP-FPM ou ne permettent pas aux clients de modifier eux-mêmes ses paramètres.

Quota CPU en cas de charge parallèle

A Quota CPU définit la quantité de temps de calcul qu'un groupe de processus est autorisé à consommer au cours d'une période donnée. Sous Linux, cgroup v2 décrit cpu.max ce budget et la période correspondante. Ce quota ne réserve donc pas automatiquement un cœur physique exclusif : il limite le temps CPU total disponible pour le groupe.

Exemple de calcul à titre illustratif, et non une mesure : un groupe se voit attribuer 100 millisecondes de temps CPU par période de 100 millisecondes. Cela correspond en moyenne au temps de calcul d’un processeur logique fonctionnant à pleine capacité. Si deux processus calculent simultanément sur deux processeurs logiques disponibles, ils peuvent théoriquement épuiser leur budget commun au bout d’environ 50 millisecondes de temps réel.

Si le budget est épuisé, les processus peuvent être ralentis jusqu'à la période suivante. Les deux workers ne disposent donc pas chacun d'un budget propre de 100 millisecondes. Le fait qu'ils s'exécutent effectivement en parallèle, et à quel moment, dépend notamment du planificateur, des processeurs disponibles et de leur comportement ; cet exemple ne permet pas de prédire un temps de réponse précis.

Pour cette étude, cgroup v2 est utilisé dans cpu.stat notamment des compteurs pour Étranglement prêts. Si ceux-ci augmentent au cours d'une phase de charge représentative, cela indique que le quota est épuisé. Un seul relevé de compteur ne permet toutefois pas de déterminer quelle demande était concernée ni s'il existe d'autres goulots d'étranglement.

C'est à toi de vérifier auprès de l'hébergeur si ces fichiers sont accessibles dans le cadre de la formule choisie et s'ils sont pertinents pour le site web. L'hébergement mutualisé peut utiliser d'autres mécanismes : CloudLinux, par exemple, documente ses propres limites LVE pour le processeur et d'autres ressources. L'exemple Linux ne permet donc pas de déduire ni la configuration concrète, ni le comportement de chaque compte d'hébergement.

CMS, boutique en ligne et tâches en arrière-plan

Lorsqu'une page CMS n'est pas mise en cache, le serveur exécute la logique d'application pour répondre à la requête et récupère les données nécessaires. Si une grande partie du traitement repose sur Fonctionnement du processeur, une puissance de calcul plus élevée par cœur peut raccourcir cette phase. Cela vaut notamment pour les calculs complexes dans le code PHP, mais pas nécessairement pour la durée totale nécessaire à l'affichage de la page.

En revanche, si cette même requête dépend principalement d'une interrogation de base de données ou d'une API externe, le processus PHP ne peut tirer parti que de manière limitée d'un processeur plus rapide pendant ce temps. Pour prendre une décision, il faut donc tenir compte de la répartition du temps de réponse côté serveur : quelle part est consacrée au calcul et quelle part à l'attente d'autres services ?

Une boutique en ligne illustre pourquoi cette question peut avoir des réponses différentes selon les pages. Les pages de produits accessibles au public peuvent, sous certaines conditions, être mises en cache en tant que réponse prête à l'emploi. Un accès au cache peut éviter un nouveau traitement PHP complet ; en revanche, le panier et la page de paiement doivent souvent prendre en compte des données spécifiques et restent dynamiques.

Un grand nombre de requêtes de checkout simultanées peut donc solliciter davantage les workers ou le budget CPU qu'un nombre équivalent d'appels de pages mises en cache. Le nombre de visiteurs ne suffit pas à lui seul à décrire cette charge : ce qui est déterminant, c'est de savoir quels points de terminaison sont sollicités simultanément et à quelle fréquence le cache est utilisé. Avec PHP-FPM, le paramètre du pool limite en outre pm.max_children le nombre de requêtes traitées simultanément.

Une importation gourmande en ressources de calcul au niveau du backend peut, à son tour, bénéficier d'un traitement individuel plus rapide. Si elle s'exécute en parallèle des requêtes des visiteurs, les processus risquent de se disputer le même budget de temps CPU. Le fait qu’une tâche cron ou une importation soit effectivement attribuée à ce même groupe limité dépend du forfait et de sa configuration ; renseignez-vous auprès du fournisseur avant de prendre une décision concernant les capacités.

Pour une comparaison pertinente, tu dois examiner ces charges de travail séparément : une requête dynamique type, une phase comportant plusieurs requêtes simultanées et, le cas échéant, l'importation en cours d'exploitation. Tu pourras ainsi mieux déterminer si c'est la vitesse d'une étape de traitement individuelle ou la capacité totale disponible qui constitue le facteur le plus déterminant.

Comparer les observations et les goulots d'étranglement

Une réponse lente n'indique pas nécessairement une cause précise. Le tableau suivant met en relation des observations typiques avec des hypothèses vérifiables. Il tient notamment compte des limites de temps d'exécution du processeur, du nombre limité de workers sous PHP-FPM et de la différence entre le code PHP mis en cache et une réponse déjà générée.

Chaque ligne du tableau est une Hypothèse, ce n'est pas un diagnostic définitif. Des réponses lentes en mode parallèle peuvent, par exemple, coïncider avec une limitation de la puissance du processeur, mais elles peuvent également être dues à des workers occupés ou à une base de données en attente. Vérifie donc, dans la mesure du possible, plusieurs signaux simultanément et pour la même charge de travail, plutôt que de conclure à un changement de forfait à partir d'un seul symptôme.

Lors de l'analyse, séparez les Temps de réponse Débit des requêtes : une réponse individuelle plus rapide ne signifie pas automatiquement qu'un nombre plus élevé de requêtes par seconde sera traité en cas de forte simultanéité. À l'inverse, un système peut atteindre un bon débit tout en faisant attendre plus longtemps les requêtes individuelles.

Le temps de chargement perçu de la page ne doit pas non plus être assimilé au temps de réponse côté serveur. Après la réponse, d'autres ressources peuvent par exemple être chargées et traitées par le navigateur. Une mise à niveau du processeur au niveau de l'hébergement ne concerne que la partie côté serveur concernée ; pour une comparaison équitable, l'état du cache, la page demandée et le parallélisme doivent rester identiques.

En ce qui concerne le cache, il est également utile de faire la distinction entre les différents concepts : OPcache stocke le code PHP compilé et permet ainsi d'éviter une nouvelle compilation. Un cache de pages, en revanche, conserve une réponse déjà générée. Une réponse rapide du cache ne prouve donc ni que les requêtes dynamiques disposent d'une puissance de calcul suffisante, ni qu'OPcache remplace la logique de l'application.

Identifier les goulots d'étranglement et les temps d'attente

Commence le diagnostic par des requêtes typiques de ton site web : par exemple, une page publique du CMS, une recherche et, s'il s'agit d'une boutique en ligne, le processus de paiement. Note si la réponse correspondante provient du cache de la page. Compare ensuite les requêtes individuelles et un nombre de requêtes simultanées représentatif de ton projet, plutôt que de te limiter au nombre total de visiteurs.

Si possible, séparez les temps CPU le temps de réponse global et les temps d'attente liés à la base de données ou aux services externes. Si la part du CPU est faible, un processeur plus rapide ne pourra réduire qu'une partie limitée de l'appel. Si tu ne disposes pas de mesures appropriées, demande au fournisseur les journaux, les métriques ou une analyse pertinente disponibles.

En cas de charge parallèle, vérifiez si les workers disponibles sont sollicités à pleine capacité et si les compteurs de limite augmentent. Limite pour PHP-FPM : pm.max_children les requêtes traitées simultanément par un pool ; la possibilité de consulter cette valeur ou le taux d'utilisation dépend du forfait. Les systèmes Linux cgroup-v2 peuvent être configurés dans cpu.stat notamment afficher des compteurs de limitation. Une augmentation de ces compteurs justifie un examen plus approfondi du budget CPU et de la période de mesure.

Si SSH et le fichier en question sont accessibles, la commande cat /proc/self/cgroup l'affectation au cgroup du processus appelant. Cela ne signifie pas pour autant que les requêtes Web s'exécutent dans le même groupe. Vérifiez les chemins d'accès, les droits et l'interprétation auprès de l'hébergeur ; de même, les codes d'erreur ne peuvent pas être systématiquement attribués à une limite spécifique de chaque système d'hébergement mutualisé.

Vérifier le cache et comparer les tarifs

Vérifie d'abord quelles pages publiques peuvent être mises en cache en toute sécurité en tant que réponse complète. Une Cache de pages peut éviter un traitement dynamique répété en cas de correspondance. En revanche, les contenus personnalisés, le panier et le processus de paiement nécessitent une stratégie de mise en cache adaptée afin que les visiteurs ne reçoivent pas de données étrangères ou obsolètes.

Une autre approche consiste à réduire la charge de travail en cas d'échecs de cache : analysez les requêtes de base de données lentes et supprimez tout traitement dynamique inutile. Dans le cas d'un service externe, son temps de réponse peut être déterminant ; dans ce cas, tu devrais d'abord examiner cet appel plutôt que de supposer d'emblée que le CPU en est la cause. La modification à apporter dépendra du chemin réellement lent.

Il convient de distinguer cela de OPcache: Il stocke le code PHP compilé, mais ne remplace ni la mise en cache complète des pages, ni l'exécution de la logique d'application. Vérifiez la disponibilité et les paramètres dans l'environnement d'exécution Web. La CLI dispose de son propre paramètre OPcache ; un simple coup d'œil à la ligne de commande ne permet donc pas de déterminer la configuration applicable aux requêtes Web.

Pour comparer les performances, vous devez comparer les mêmes requêtes avec les mêmes versions logicielles, un ensemble de données comparable et un état de cache consigné. Répétez la comparaison avec le même niveau de parallélisme et tenez compte des budgets disponibles en termes de CPU, de workers et de mémoire. Sinon, une différence pourrait résulter des conditions de test sans pour autant fournir d'informations fiables sur les performances du processeur.

Notez également séparément le temps nécessaire pour chaque réponse et le nombre de requêtes traitées au cours d'une période donnée. Un forfait peut sembler avantageux pour une seule requête, mais atteindre ses limites en cas de charge simultanée. Les valeurs issues d'une comparaison ne s'appliquent dans un premier temps qu'à l'application étudiée et à ses conditions spécifiques.

Un processeur plus rapide ou un budget plus important ?

Si une requête dynamique représentative sollicite principalement le processeur et qu'aucun facteur (ni les workers, ni la mémoire, ni le budget-temps) ne constitue une contrainte, une valeur plus élevée de Puissance par cœur une option tarifaire plausible. Elle peut réduire la partie de la requête individuelle consacrée au calcul. L'impact de cette réduction sur la réponse globale dépend toutefois toujours de l'application et de ses temps d'attente.

Si, en revanche, les données indiquent un ralentissement ou des workers saturés en cas de requêtes simultanées multiples, vérifie s'il est nécessaire d'augmenter la taille Budget des ressources. Une augmentation du temps CPU peut s'avérer utile lorsque la limite de quota est atteinte ; les workers supplémentaires ont toutefois besoin à la fois de mémoire suffisante et de temps de calcul. Si la base de données ou des services externes constituent le goulot d'étranglement, une augmentation du budget CPU ne constitue pas à elle seule une solution fiable.

Avant de changer de solution, il est utile de comparer cette option avec l'optimisation de l'installation existante. Un cache de pages adapté ou une requête améliorée peut réduire la charge de travail dynamique sans que tu aies immédiatement besoin d'un forfait plus élevé. Répète le diagnostic après une modification, dans des conditions comparables, afin de pouvoir distinguer son effet des autres facteurs.

A Le VPS, une alternative à l'hébergement mutualisé offre généralement davantage de contrôle sur les logiciels et la configuration, mais implique également davantage de responsabilités en matière de sécurité, de mises à jour et de planification des capacités. Sauf engagement explicite du fournisseur, les processeurs virtuels ne correspondent pas à des cœurs physiques dédiés. Vérifiez donc également l'attribution concrète des ressources et les conditions contractuelles à cet égard.

Avant de prendre votre décision, renseignez-vous auprès du fournisseur sur le modèle de processeur, la définition du budget de temps CPU et la gestion des pics de charge. Précisez également quelles sont les limites en matière de workers et de mémoire, si les tâches en arrière-plan partagent le même budget et quels compteurs de limites vous pouvez consulter. Ce ne sont que ces informations qui permettent de situer la puissance CPU annoncée par rapport à votre forfait spécifique.