Benchmark de serveur cloud : identifier les configurations gonflées grâce à des tests forensiques

Démasquez les configurations gonflées grâce à un benchmark forensique et déterminez le vrai rapport qualité-prix.

Mis à jour 2026-08-23 · CloudWorth

benchmarkconfiguration gonfléeSteal Timesurréservationtaux de surcoûtCloudWorthSurvente VPSBenchmark VPS

Le benchmark ne se résume pas à des chiffres : croisez Steal Time et taux de surcoût pour refuser de payer pour du vent.

Benchmark forensique : Steal Time et générations de CPU

Ce que l'on redoute le plus en achetant un serveur cloud n'est pas un score faible, mais un « score gonflé » — la fiche technique indique EPYC 9006, mais on obtient en réalité d'anciens cœurs ; le cache disque affiche 1,2 Go/s, mais chute à 200 Mo/s dès qu'on fait un test de charge. C'est ce qu'on appelle des spécifications trompeuses. Mon approche : d'abord lancer un benchmark forensique de 30 minutes, puis confronter les chiffres à la facture.

Première étape : le Steal Time. Dans top, si %steal dépasse 5%, il faut se méfier ; au-delà de 15%, cela signifie que le voisin dévore votre CPU. Utilisez vmstat 1 pour un échantillonnage continu. Si le steal fluctue fortement et s'accompagne d'une charge élevée, la surallocation est grave. Ces machines, même avec un score élevé, se bloquent dès que le trafic augmente.

Deuxième étape : la génération du CPU. Ne vous fiez pas uniquement à lscpu ; vérifiez avx512 et sse4_2 dans les flags, et comparez le modèle réel avec l'annonce. Un ancien Xeon a aussi 8 cœurs, mais son IPC est trois générations en retard ; la prime pour la même configuration devrait être inférieure de 30%+. En combinant avec le taux de prime FinOps, je transforme « score annoncé ÷ prix de location réel » en tableau : la part de surallocation dans le prix unitaire devient immédiatement visible.

Les commandes détaillées sont dans la liste de benchmarks CloudWorth, qui génère un pack forensique à soumettre au support.

Audit du taux de prime : calculer le vrai rapport qualité-prix

Les scores ne sont que le début, ce qui compte vraiment, c'est le taux de prime – c'est-à-dire combien de puissance de calcul effective chaque dollar achète. Peu importe à quel point le benchmark du serveur cloud est élevé, si le Steal Time est constamment > 10%, cela signifie que les voisins volent du CPU, la survente est probable, et ce type de configuration trompeuse est plus caché que la falsification de paramètres.

Ma propre formule d'audit est simple :

• Puissance de calcul effective = score monocœur × proportion de temps CPU stablement occupable (1 - proportion de steal)
• Taux de prime = puissance de calcul effective ÷ prix de renouvellement réel, et non le prix promotionnel de première commande

Note : Sortez le prix de renouvellement et comparez-le avec le cloud public. Pour un même EPYC, une ancienne génération ne vaut que si elle est 20% moins chère qu'une nouvelle génération ; si le nouveau modèle est vendu à l'ancien prix, le taux de prime est problématique.

Lors de la mise en pratique, commencez par un test de charge de 30 minutes pour capturer le steal :

vmstat 1 300 | awk 'NR>1{sum+=$16;n++} END{print "avg steal %:", sum/n}'

Si la moyenne de steal dépasse 5%, regroupez les résultats de benchmark et les captures d'écran des tickets de support dans un PDF – cela deviendra la chaîne de preuves pour les réclamations et remboursements ultérieurs. Ce n'est qu'après avoir calculé le taux de prime que vous devriez commander ; c'est ainsi que l'on paie pour un vrai rapport qualité-prix, plutôt que de payer des frais de scolarité pour des configurations trompeuses.

Boucle de revendication via ticket : chaîne de preuves et compensation pour déclassement

Si vous découvrez un problème lors des benchmarks, ne vous précipitez pas pour désinstaller et réinstaller. Exécutez d'abord une série de commandes d'investigation horodatées, par exemple vmstat 1 30 pour capturer les pics de Steal Time, puis des tests dd successifs pour mesurer la chute brutale du cache disque, et enfin lscpu pour archiver la génération réelle du CPU. Enregistrez ces sorties au format PDF, avec la date et l'ID de l'instance — c'est la chaîne de preuves que vous pourrez opposer au service client.

Lorsque vous soumettez un ticket, ne dites pas simplement « ça rame ». Écrivez directement : « Le Steal Time dépasse 30 % en continu, le taux de surcoût par rapport à la configuration du marché est supérieur de 40 %, je soupçonne une surréservation et un déclassement ». La plupart des fournisseurs vous enverront d'abord un script de test pour une re-vérification. Dans ce cas, exécutez-le à l'identique et faites une capture côte à côte des deux résultats. Si la surévaluation est confirmée, privilégiez une négociation sur la compensation pour déclassement : soit un remboursement de la différence basé sur les performances réelles, soit une mise à niveau gratuite vers un CPU de même génération. Le meilleur cas que j'ai vu est d'avoir obtenu une exonération de trois ans de frais de trafic grâce aux données de Steal Time — à condition de présenter aussi le taux de surcoût aux finances. L'approche FinOps est plus efficace ici que les termes techniques.

N'oubliez pas de conserver tous les numéros de ticket. Après réception de la compensation, effectuez un nouveau test pour vérifier que les chiffres correspondent à la facture. La défense de vos droits n'est pas une dispute, c'est un échange équitable basé sur des preuves.