Benchmarking des processeurs de serveurs pour PHP : tests sur des charges de travail réelles d'hébergement web

Ce qu'un benchmark PHP est censé révéler

Un benchmark CPU PHP permet tout d'abord de déterminer le temps nécessaire à un système pour effectuer une tâche de calcul donnée. Cela s'avère particulièrement utile lorsqu'une requête individuelle passe beaucoup de temps à effectuer des calculs PHP. Une valeur plus élevée Performances monocœur peut réduire le temps de traitement de ce type de tâches ; toutefois, la valeur du CPU ne permet pas à elle seule de déterminer le temps de réponse d'un site web dans son ensemble.

Une deuxième question concerne le comportement de l'application en cas d'accès simultanés : combien de réponses correctes fournit-elle par seconde, et quel est le temps d'attente des utilisateurs dans ce cas ? Pour cela, il faut un Comparatif d'hébergement web via HTTP. Il prend en compte le parcours à travers les serveurs Web et PHP, ainsi que, le cas échéant, la base de données, le cache et le réseau. C'est précisément cette combinaison qui le rend proche de la réalité, mais qui empêche de tirer des conclusions isolées concernant le CPU.

La troisième question concerne le goulot d'étranglement. Si une requête attend, par exemple, le résultat d'une interrogation de base de données, une opération de calcul plus rapide ne permet pas de tirer de conclusions sur sa durée totale. Le cache influe également sur le résultat : si une page est déjà entièrement servie avant l'exécution de PHP, l'appel ne mesure pas l'exécution de l'application dynamique.

En cas de charge parallèle, le pool PHP-FPM peut également limiter le nombre de requêtes traitées simultanément. Sa page d'état fournit notamment des informations sur les processus occupés et les requêtes en attente. Une file d'attente qui s'allonge est donc un motif de diagnostic, et non une preuve immédiate d'un processeur trop lent.

Pour choisir un hébergement, il est utile d'examiner ces questions séparément : d'abord l'unité de travail comparable, puis le fonctionnement en cas de charge faible et élevée, et enfin les ressources qui limitent le résultat. L'article consacré à Matériel pour l'hébergement web haute performance.

Distinguer les scores CPU et les tests d'applications

A Microbenchmark répète une petite tâche précisément définie. PHPBench permet, par exemple, d'analyser une fonction de traitement de données dans des conditions prédéfinies. Le résultat aide à comparer cette fonction et son environnement d'exécution ; il ne décrit ni automatiquement une requête complète, ni les performances d'un CMS ou d'une boutique en ligne.

Un test d'application HTTP répond à une autre question : comment l'application choisie réagit-elle via la pile web effectivement utilisée ? Il prend en compte, par exemple, PHP-FPM, la base de données et les caches, dans la mesure où ils interviennent dans l'appel testé. Il est donc adapté à l'évaluation d'une offre d'hébergement, mais ne permet pas à lui seul de déterminer quel composant est à l'origine d'une différence.

SPEC CPU complète ces tests par des charges de travail standardisées et très gourmandes en calcul. SPEC CPU 2026 comprend des suites de tests sur les entiers et en virgule flottante, ainsi que des résultats de type « Speed » et « Rate ». « Speed » fait référence au temps nécessaire pour effectuer les tâches, tandis que « Rate » correspond au débit. Une valeur de vitesse n'est pas automatiquement une valeur purement monocœur : SPEC signale un parallélisme supplémentaire lors des tests de vitesse sur les nombres entiers de la suite 2026.

Pour une comparaison SPEC fiable, la suite, la métrique et le type de résultat doivent base ou pic correspondent. Le système testé dans son intégralité est également pris en compte : outre le processeur, la mémoire, le compilateur et la configuration, entre autres, influencent le résultat. Les valeurs publiées ne constituent donc pas une caractéristique isolée du modèle de processeur et ne remplacent en aucun cas un test PHP.

SPEC CPU 2017 et CPU 2026 utilisent des suites de tests différentes ; leurs résultats ne sont pas comparables. Si vous effectuez une présélection, vous devriez donc comparer le rapport complet des résultats plutôt qu’un classement abrégé. Seul un test d’application adapté permettra ensuite de déterminer si un processeur est adapté à votre utilisation.

Définir des conditions de test comparables

Pour qu'une comparaison soit équitable, il faut partir d'une même version de l'application et d'un ensemble de données comparable. L'itinéraire choisi et la réponse attendue doivent également correspondre : une page produit impliquant de nombreux accès à la base de données répond à une question différente de celle posée par une simple fonction API. Vérifie donc non seulement si une réponse est renvoyée, mais aussi si son contenu correspond bien à la tâche prévue.

Notez la version de PHP et ses extensions, ainsi que le serveur web, la configuration de PHP-FPM et la base de données. Le chemin réseau entre le générateur de charge et l'application doit également figurer dans le rapport. Des chemins ou des emplacements de base de données différents peuvent modifier le temps de réponse mesuré, même si l'exécution de PHP était aussi rapide sur les deux systèmes.

Il est particulièrement important de distinguer CLI et PHP-FPM: Un test en ligne de commande n'utilise pas automatiquement la même configuration d'exécution qu'une requête HTTP. Documentez les paramètres OPcache et JIT effectivement utilisés dans ces deux contextes. Leur effet et leurs valeurs par défaut dépendent notamment de la version de PHP ; une hypothèse générale ne suffit pas pour la comparaison.

De même, le État du cache doit être comparable. Un cache « à froid » et un cache déjà « réchauffé » apportent des réponses différentes ; les deux peuvent être pertinents, mais doivent être analysés séparément. Il en va de même pour le volume de données et les données de test : si l'étendue du travail change, une différence de temps ne peut plus être attribuée de manière précise au système.

Notez également le modèle de processeur, les vCPU attribués et les limites de ressources visibles, ainsi que la charge choisie et le nombre de répétitions. Si l'on compare délibérément deux forfaits d'hébergement différents, le résultat fournit des informations sur leur configuration globale respective. Les différences au niveau du processeur, des limites, de la base de données ou de la mise en cache ne doivent alors pas être interprétées comme un avantage du processeur sans un diagnostic plus approfondi.

Choisir les charges de travail et les indicateurs adaptés

Le choix du test dépend de la question à laquelle tu souhaites répondre. Un Microbenchmark examine une tâche de calcul limitée ; un test HTTP prend en compte le parcours à travers la pile Web. Les résultats SPEC complètent la comparaison par des tests système standardisés sollicitant fortement le processeur, mais ne remplacent pas un test de votre propre application PHP.

Pour une requête dynamique unique, choisissez une page ou une route API représentative et commencez avec un faible niveau de parallélisme. La route doit effectivement exécuter du code PHP : une réponse entièrement fournie par un cache de pages en amont constituerait certes un test de cache valable, mais ne donnerait que peu d'informations sur le traitement PHP.

Pour les visiteurs simultanés, tu testes le même point de terminaison à plusieurs niveaux de charge prédéfinis. Cela permet de déterminer si les temps de réponse et le débit réussi varient à mesure que le parallélisme augmente. Dans le cas d'un parcours faisant un usage intensif de la base de données, le volume de données, l'emplacement de la base de données et l'état du cache doivent rester identiques d'une exécution à l'autre.

Tu peux analyser de manière isolée, à l'aide de PHPBench, une fonction de l'application qui sollicite fortement le processeur, par exemple un traitement de données sans accès au réseau. Un meilleur résultat ne montre dans un premier temps qu'un avantage pour cette fonction dans les conditions d'exécution choisies. Seul le test de l'application permettra de déterminer si cela se traduit par un avantage perceptible pour une page complète.

Effectuer un test de staging avec wrk

Ne procédez à ces tests que dans un environnement de préproduction isolé, avec une autorisation expresse. Configurez un parcours de lecture représentatif et sans risque, et utilisez des données de test appropriées. Avant de commencer, définissez une charge maximale ainsi que des critères d'arrêt, tels que l'apparition d'erreurs, des délais d'attente ou une perturbation d'autres services.

La commande suivante est destinée à être exécutée sur un terminal connecté à une instance de staging locale spécialement configurée à cet effet. La route préparée doit être accessible sur le port 8080 ; cette commande génère en effet une charge et n'est pas destinée à être exécutée sur un système inconnu ou en production.

wrk -t2 -c4 -d30s --latency http://127.0.0.1:8080/

L'appel utilise deux threads de génération de charge, quatre connexions ouvertes et une durée d'exécution de 30 secondes. L'option --latency demande un rapport détaillé sur la latence. Le choix de quatre connexions constitue un point de départ pour cet exemple, et non une recommandation générale concernant le nombre de visiteurs ou la capacité d'un serveur.

Cependant, la sortie standard des centiles de wrk ne contient pas de p95. Pour obtenir une analyse reproductible du p95, enregistrez le script Lua suivant sur le générateur de charge sous le nom percentiles.lua. Les valeurs p50 et p95 issues des statistiques de latence sont exprimées en microsecondes ; en les divisant par 1 000, on obtient des millisecondes.

function done(summary, latency, requests)
  io.write(string.format("p50: %.0f us\n", latency:percentile(50.0)))
  io.write(string.format("p95: %.0f us\n", latency:percentile(95.0)))
end

Pour la mesure proprement dite, lancez le même test de mise en place local à l'aide du script. Le chemin d'accès au fichier s'applique à un terminal situé dans le répertoire contenant le fichier de script. Cet appel génère lui aussi une charge ; consignez les deux centiles affichés, ainsi que les erreurs et la qualité de la réponse vérifiée séparément.

wrk -t2 -c4 -d30s --latency -s percentiles.lua http://127.0.0.1:8080/

Prévois une Échauffement avant de consigner les mesures proprement dites. Répétez ensuite chaque niveau de charge défini et variez si possible l'ordre des systèmes de comparaison. Notez la durée de préchauffage et indiquez si le cache se trouvait dans l'état souhaité au début de la mesure.

N'augmentez le nombre de connexions que dans les limites convenues et vérifiez les critères d'interruption après chaque étape. Surveillez également le générateur de charge : s'il est lui-même saturé, il peut limiter le résultat. Vérifiez également les codes d'état et le contenu des réponses ; une page d'erreur affichée rapidement ou une réponse erronée ne sont pas considérées comme une requête d'application réussie.

Consigner les niveaux de charge et les résultats

Un rapport de mesure établit un lien entre les chiffres et les conditions dans lesquelles ils ont été obtenus. Pour chaque exécution, note l'environnement, le point final, l'état du cache et le niveau de charge, ainsi que les résultats. Le tableau suivant utilise notamment des valeurs fournies par wrk ou la page d'état FPM ; tu dois compléter la vérification du contenu de la réponse.

La médiane correspond à la valeur centrale des temps de réponse observés. La p95 Il s'agit de la valeur que 95 % des réponses mesurées ne dépassent pas. Ensemble, ces deux indicateurs permettent de déterminer si, outre les requêtes typiques, la partie la plus lente de la distribution évolue également. Il convient de toujours les interpréter en tenant compte des erreurs et des délais d'expiration.

Il convient de distinguer un nombre fixe de connexions d'un taux de requêtes prédéfini. Dans le cadre d'un test basé sur les connexions, comme dans l'exemple, des réponses lentes peuvent entraîner une diminution du nombre de nouvelles requêtes par seconde générées via ces mêmes connexions. La latence mesurée ne reflète alors pas nécessairement le comportement observé avec un taux d'arrivée élevé et constant.

Ne comparez donc que des points de charge suffisamment similaires : même itinéraire et même test de réponse, états de cache comparables, ainsi que même modèle de charge et même niveau de charge. Un p95 faible avec un faible degré de parallélisme n’est pas directement comparable à un p95 en condition de surcharge. Rendez compte de plusieurs exécutions et de leur dispersion, plutôt que de présenter une seule valeur favorable comme résultat.

Analyser le FPM et les limites de ressources

Si, à mesure que la charge augmente, la file d'attente et le temps de réponse p95 augmentent tous les deux, il vaut la peine de jeter un œil au pool PHP-FPM. Comparez les valeurs actuelles pour active processes, idle processes et listen queue avec la limite maximale configurée pm.max_children. Si tous les processus autorisés sont actifs, qu'aucun n'est libre et que des requêtes sont en attente, cela indique une limite du pool ou à des processus qui s'exécutent depuis longtemps, mais pas nécessairement à un processeur trop lent.

L'annonce max children reached En revanche, elle indique que la limite du nombre de processus a été atteinte plus tôt depuis le démarrage du pool. À elle seule, elle ne prouve ni l'existence d'une file d'attente actuelle, ni le fait que tous les processus existants soient actuellement occupés. De même, le nombre maximal de processus existants ne signifie pas que tous soient actifs.

Les workers peuvent également être en attente de requêtes de base de données ou d'autres services externes. Comparez donc l'état du pool et l'utilisation du processeur avec les temps de réponse observés : une file d'attente pleine associée à une faible utilisation du processeur suggère d'examiner en premier lieu les temps d'attente et l'occupation des workers. Augmenter le nombre de pools n’est pas automatiquement la solution, car les processus supplémentaires consomment eux aussi des ressources.

Les valeurs d'état FPM s'appliquent au pool concerné ; les compteurs sont remis à zéro lors d'un redémarrage. Notez donc le pool et l'heure du redémarrage dans le journal de mesure et ne comparez les valeurs des compteurs que sur une période appropriée. Protégez une page d'état activée contre tout accès non autorisé, car elle divulgue des informations d'exploitation concernant le pool.

Dans le cas des serveurs VPS et de l'hébergement mutualisé, un vCPU attribué ne correspond pas nécessairement à un cœur physique exclusif. Lorsque les données cgroup-v2 sont accessibles, la commande cpu.max la limite de bande passante du processeur configurée ; cpu.stat peut notamment comporter des compteurs pour Throttling sont inclus. Les modifications apportées à ces compteurs au cours d'une exécution aident à déterminer s'il s'agit d'une limitation effective.

Si possible, vérifiez également les cgroups de niveau supérieur : une limite définie à ce niveau peut influencer le temps de calcul disponible, même si la configuration directement visible semble généreuse. Tous les compteurs ne reflètent pas intégralement les limites héritées. Si ces informations ne figurent pas dans la offre d'hébergement, cette visibilité limitée fait expressément partie des limites de l'analyse.

Détecter la dispersion et les erreurs de mesure

Un seul test peut donner une image aléatoire, favorable ou défavorable. Répétez les mêmes niveaux de charge à des moments bien précis et, dans la mesure du possible, variez l'ordre des systèmes comparés. La puissance disponible peut varier, notamment lorsque les ressources sont partagées ; c'est pourquoi vous devez indiquer, en plus d'un résultat typique, la valeur observée dispersion et le nombre de courses.

Veillez à ce que les exécutions utilisent le même état de cache et le même ensemble de données. Une exécution avec un cache de pages ou de base de données « chaud » n'est pas directement comparable à une exécution « à froid ». Si une réponse apparemment plus rapide provient entièrement d'un cache de pages, elle ne donne que peu d'indications sur la vitesse à laquelle PHP effectue le travail dynamique.

Un micro-benchmark CLI ne correspond pas non plus à un résultat FPM : il s'exécute dans un contexte d'exécution différent et peut utiliser d'autres paramètres OPcache ou JIT. Documentez séparément les paramètres effectivement actifs des deux environnements d'exécution, au lieu de les déduire de la version de PHP. Un avantage observé lors d'un micro-benchmark ne se traduira pas nécessairement par un avantage de même ampleur lors du test HTTP de l'application.

Ne prends en compte dans le débit effectif que les réponses correctes sur le fond et abouties. Sinon, les pages d'erreur s'affichant rapidement ou les délais d'expiration peuvent fausser considérablement la comparaison. En cas d'écarts notables, vérifie également les temps d'attente de la base de données, les modifications apportées au cache et les limites de ressources visibles avant d'attribuer la différence uniquement au processeur.

Le Comportement en matière de cadence peut également contribuer à la dispersion. Le réglage de fréquence approprié dépend de la plateforme et de la charge ; un réglage général ne remplace pas une comparaison effectuée dans les mêmes conditions. La contribution à la Régulateur de CPU sur les serveurs d'hébergement explique les liens entre ces éléments en vue d'une analyse approfondie.

Utiliser les résultats pour choisir un hébergeur

Pour les requêtes qui sollicitent principalement le processeur, la Durée par session de travail un critère de sélection important. Pour cela, comparez une fonction PHP représentative dont la durée d'exécution est documentée, puis vérifiez si cet avantage se confirme également avec le routage HTTP dynamique. Un micro-benchmark ne décrit dans un premier temps que le code testé, et non l'ensemble de l'offre d'hébergement.

Si vous prévoyez un nombre élevé de visiteurs simultanés, la rapidité de traitement d'une requête unique ne suffit pas. Il est également essentiel de déterminer le nombre de réponses correctes par seconde fournies par le système à un niveau de charge donné, ainsi que le comportement de la latence p95 dans la marge d'erreur acceptée. Un système offrant un débit plus élevé n'est pas automatiquement mieux adapté à ton projet si la lenteur de ses réponses dépasse les exigences.

Pour les applications dépendantes d'une base de données ou d'un cache, pondérez le Test d'application plus qu'un score CPU. Un parcours type avec un ensemble de données comparable montre comment la pile fonctionne dans les conditions choisies. Un résultat SPEC peut compléter la présélection, mais il décrit un système testé et ne remplace pas un test d'hébergement web PHP.

Avant de faire votre choix, déterminez quels temps de réponse, taux d'erreur et niveaux de charge sont acceptables pour l'application. Compare ensuite uniquement les résultats correspondant à un modèle de charge approprié et à un état de cache comparable. Évalue les différentes offres d'hébergement comme des configurations globales ; leur écart ne permet pas de déterminer la part du processeur sans diagnostic supplémentaire.

Cette décision s'applique à l'état actuel mesuré, et non à chaque version ultérieure de l'application ou à chaque pic de trafic. Répétez les tests pertinents après toute modification importante apportée à PHP, à l'application, à la base de données, au cache ou aux limites de ressources. Vous pourrez ainsi déterminer si les réserves, qui étaient auparavant suffisantes, le restent dans les nouvelles conditions.