Comment bien benchmarker un VPS

Ce que signifie l’évaluation comparative d’un VPS

Évaluer un VPS consiste à mesurer quatre éléments : la vitesse d’exécution d’un seul cœur de CPU, la bande passante mémoire de la machine, le nombre de petites opérations aléatoires que le stockage traite chaque seconde et le débit fourni par la liaison réseau. Une exécution de yabs.sh fournit ces quatre mesures en environ dix minutes. L’interprétation du résultat est plus difficile, car un VPS partage le matériel physique avec d’autres clients. La même machine peut donc afficher une valeur à 03:00 et une valeur très différente à 20:00.

Commencez par exécuter yabs.sh pour obtenir une vue d’ensemble rapide, puis exécutez manuellement les outils qu’il utilise. En les exécutant vous-même, vous pouvez modifier un flag, observer l’évolution de la valeur et comprendre ce qu’elle mesurait réellement. Faites-le après avoir configuré la machine, et non avant. Les étapes de la première dizaine de minutes sur un nouveau VPS viennent d’abord, car une machine qui installe encore sa première série de mises à jour donne de mauvais résultats pour des raisons sans rapport avec le matériel.

Examinez la machine avant de la mesurer

La moitié des mauvais benchmarks vient d’une machine que leur auteur n’a pas comprise.

nproc
lscpu | grep -E 'Model name|Hypervisor|Thread'
free -h
df -hT /
uname -r
systemd-detect-virt

Hypervisor vendor: KVM signifie virtualisation complète : vous utilisez donc votre propre kernel. L’affichage de lxc ou de openvz par systemd-detect-virt indique au contraire une virtualisation par conteneur : vous partagez le kernel de l’hôte, et vos limites de CPU et de mémoire sont définies par des paramètres cgroup (control group), pas par du matériel virtuel. Sur un système cgroup v2, vous pouvez lire directement la limite CPU.

cat /sys/fs/cgroup/cpu.max

max 100000 signifie qu’il n’y a aucun quota. 200000 100000 signifie que vous pouvez utiliser 200000 microsecondes de CPU pendant chaque période de 100000 microsecondes, soit un quota équivalent à deux cœurs. Une offre annoncée avec 4 vCPU et un quota de deux cœurs n’obtiendra jamais les performances de quatre cœurs, et aucun outil de benchmark n’affiche une ligne expliquant pourquoi.

df -hT / est important pour une autre raison : la colonne Type. Si elle contient overlay, vous êtes dans un conteneur et le test de disque ci-dessous doit être adapté. Notez-le maintenant.

Surveillez le steal time pendant toute la durée du test

Le steal time correspond à la part du temps pendant laquelle votre CPU virtuel était prêt à s’exécuter, mais où l’hyperviseur a attribué le cœur physique à une autre machine virtuelle. C’est le signal unique le plus utile pour déterminer si un résultat dépend de vos voisins plutôt que du matériel.

vmstat 1 10

Lisez la colonne st à droite. Une valeur stable de 0 ou 1 est normale. Des valeurs durablement supérieures à 5 indiquent que l’hôte est surchargé à ce moment-là. Tous les chiffres CPU relevés pendant cette période sont donc inférieurs à la réalité, sans que votre machine soit en cause. top affiche la même valeur que %st sur la ligne du CPU. Laissez vmstat 1 s’exécuter dans une seconde session SSH pendant le benchmark, puis notez la valeur du steal time à côté de chaque résultat.

Commencez avec yabs.sh

yabs.sh (Yet Another Bench Script) est un script shell qui télécharge les binaires statiques de fio, iperf3 et Geekbench, les exécute, puis affiche un résumé unique. C’est le langage commun des discussions sur les benchmarks de VPS. Un résultat yabs est donc le moyen le plus rapide de comparer vos résultats avec ceux d’une autre personne.

La commande sur une ligne fournie par le projet est la suivante.

curl -sL yabs.sh | bash

Cette commande envoie directement à un shell le contenu actuellement fourni par l’URL. Téléchargez le script, lisez-le, puis exécutez-le.

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

Les options se placent après -s -- lorsque vous utilisez un pipe, ou directement après le nom du fichier lorsque vous exécutez une copie locale. Les options utiles sont les suivantes : -f ignore le test du disque, -i ignore le test réseau, -g ignore Geekbench, -r limite à deux le nombre d’emplacements iperf3, -j affiche les résultats au format JSON et -w results.json écrit ce JSON dans un fichier.

bash yabs.sh -r -w yabs-run1.json

Deux points sont à connaître avant la première exécution. Geekbench téléverse votre résultat et affiche une URL publique de browser.geekbench.com. Toute personne disposant de ce lien peut donc consulter le modèle de votre CPU et vos scores. -g ignore complètement ce test. Ensuite, l’étape iperf3 génère du trafic réel vers des serveurs situés dans plusieurs régions. Ce trafic est décompté de votre quota mensuel de bande passante. Sur une liaison à 1 Gbit/s, une étape réseau complète peut transférer plusieurs dizaines de gigaoctets. Utilisez donc -r avec un petit quota et -i sur une liaison facturée à l’usage.

Ce que signifie chaque partie de la sortie de yabs

La section du disque exécute fio avec un mélange de lectures et d’écritures à parts égales, pour quatre tailles de blocs : 4k, 64k, 512k et 1m. Elle indique les IOPS (opérations d’entrée/sortie par seconde) et la bande passante pour chacune. La ligne 4k est celle qui compte pour une base de données, un serveur de messagerie ou toute charge effectuant de nombreuses petites écritures, car la plupart des opérations d’E/S des serveurs sont de petite taille et dispersées. La ligne 1m concerne les sauvegardes et la vidéo, qui déplacent de longues séquences d’octets.

La section réseau exécute iperf3 contre des serveurs publics situés dans plusieurs régions, dans les deux sens, en utilisant des flux parallèles. Considérez un résultat faible comme une question, et non comme une conclusion, car les serveurs iperf3 publics sont partagés et souvent saturés. Le mauvais résultat peut donc venir de l’extrémité distante.

La section Geekbench fournit un score single core et un score multi core. Le score single core indique la vitesse à laquelle une requête, une compilation ou une requête SQL s’exécute. Le score multi core indique principalement combien de cores vous avez réellement obtenus.

Disk : exécutez fio vous-même

fio (flexible IO tester) est l’outil utilisé par la section disque de yabs. L’exécuter directement permet de comprendre la signification des options.

sudo apt update && sudo apt install -y fio sysbench iperf3

Voici un test de lecture aléatoire en blocs de 4k, avec une profondeur de file d’attente de 32, sur le système de fichiers qui vous intéresse réellement :

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

La ligne de synthèse à relever dans la sortie se présente comme suit.

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

fio affiche ensuite un bloc clat percentiles. Le 99.00e percentile est la valeur à citer, car il indique combien de temps a attendu la requête la plus lente sur 100. Une latence moyenne masque précisément les blocages perceptibles par l’utilisateur.

• --direct=1 ouvre le fichier avec O_DIRECT, afin que les lectures contournent le cache de pages du noyau. Sans cette option, le deuxième passage sur un fichier de 2G, sur une machine équipée de 8G de RAM, est servi depuis la mémoire et fio indique des IOPS qui se comptent en millions. Cette valeur est réelle, mais elle mesure la mémoire.
• --ioengine=libaio soumet des requêtes asynchrones, ce qui permet à --iodepth=32 d’en maintenir 32 en cours. Avec un moteur synchrone tel que psync, une profondeur de file supérieure à 1 ne sert à rien : vous mesurez une requête à la fois.
• --time_based --runtime=60 exécute le test pendant 60 secondes fixes au lieu d’exécuter une quantité de travail fixe. Un disque rapide et un disque lent utilisent ainsi la même durée réelle, ce qui garantit une comparaison équitable.
• --size=2G définit la taille du fichier de test. Conservez une taille supérieure à celle de tous les caches présents sur le chemin et vérifiez d’abord que vous disposez de suffisamment d’espace libre.

Pour les écritures aléatoires, utilisez la même commande avec --rw=randwrite. Exécutez le test séparément, puis supprimez le fichier.

fio --name=randwrite4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randwrite --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f ./fio-testfile

Pour un mélange plus proche du trafic réel, utilisez --rw=randrw --rwmixread=70. La classe de stockage utilisée influence davantage ces résultats que n’importe quelle option. Cette différence est expliquée dans la différence entre le stockage NVMe et le stockage SSD SATA sur un VPS.

Quand fio s’arrête avec l’erreur « Unknown error -1 »

Les E/S directes ne sont pas disponibles sur tous les systèmes de fichiers. overlay, le système de fichiers que Docker attribue par défaut à un conteneur, ainsi que plusieurs systèmes de fichiers réseau ne prennent pas en charge O_DIRECT. libaio soumet donc une requête que le noyau ne peut pas exécuter, et fio abandonne :

fio: io_u error on file ./fio-testfile: Unknown error -1: read offset=0, buflen=4096
fio: pid=1234, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1

Exécutez d’abord df -hT .. Si la colonne Type indique overlay, faites pointer --filename vers un chemin situé sur un stockage réel, par exemple un volume monté avec bind mount, ou exécutez fio sur l’hôte plutôt que dans le conteneur. Si le stockage réel n’est pas accessible, une exécution synchrone avec mise en cache permet au moins de vérifier que la commande elle-même est correcte.

fio --name=randread4k-buffered --filename=./fio-testfile --size=256M --bs=4k \
  --rw=randread --ioengine=psync --direct=0 --numjobs=1 \
  --runtime=15 --time_based --group_reporting
rm -f ./fio-testfile

Interprétez correctement le résultat de cette exécution. Après le premier passage, le fichier de 256M reste dans le page cache. La valeur d’IOPS décrit donc votre RAM. Utilisez cette exécution pour vérifier que fio est installé et que les options sont correctement interprétées. Ne la présentez jamais comme un résultat disque.

Pourquoi dd n’est pas un outil de benchmark de disque

dd apparaît dans de nombreux échanges sur les VPS, et répond à une question précise.

dd if=/dev/zero of=./ddtest bs=1M count=1024 oflag=direct conv=fdatasync
rm -f ./ddtest

Cette commande mesure le débit d’écriture séquentielle avec un thread et une seule requête en cours. C’est un contrôle rapide raisonnable. Elle ne dit rien des E/S aléatoires ni du comportement du système lorsque 32 requêtes arrivent simultanément. Supprimez oflag=direct : la mesure porte alors principalement sur la rapidité avec laquelle le kernel accepte les écritures en mémoire. C’est pourquoi les valeurs dd citées dans les forums sont souvent absurdes.

CPU : sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

La valeur à retenir est events per second. Commencez par un test mono-thread. Elle détermine la rapidité avec laquelle une requête PHP se termine ou une tâche de compilation aboutit. Elle varie aussi le plus entre des hôtes proposés au même prix. Lancez ensuite le test avec tous les threads. Vous verrez ainsi si vos vCPU correspondent à des cœurs distincts ou à des portions de temps processeur partagées.

Précisez ce que mesure ce test : sysbench cpu recherche de manière répétée des nombres premiers avec des opérations sur des entiers 64 bits. Il ne sollicite ni la bande passante mémoire, ni les unités vectorielles, ni le cache d’une manière représentative d’une charge réelle. Il convient donc pour classer deux hôtes, mais pas pour prévoir le comportement de votre application.

Ubuntu 24.04 fournit sysbench 1.0.20, dans lequel le nom du test vient en premier. Si vous copiez une commande avec --test=cpu depuis un ancien article, vous obtenez WARNING: the --test option is deprecated. Les scores de sysbench 0.4 et de sysbench 1.0 ne sont absolument pas comparables. Ne vous comparez donc jamais à une valeur publiée qui n’indique pas sa version.

Mémoire : sysbench memory

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write --threads=1 run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read --threads=1 run

Le résultat est exprimé en MiB/sec. Les lectures sont plus rapides que les écritures sur toutes les machines. Conservez --memory-block-size à 1M et utilisez exactement la même valeur sur tous les hôtes comparés. Avec 1K, le résultat s’effondre, car le surcoût de chaque opération est payé mille fois plus souvent. Vous mesurez alors le coût de la boucle plutôt que la bande passante mémoire. C’est l’option la plus souvent différente dans les scores mémoire publiés.

Réseau : iperf3

La méthode fiable pour tester le débit consiste à utiliser une deuxième machine que vous contrôlez. Vous savez ainsi ce que font les deux extrémités.

Sur la machine distante :

iperf3 -s

Cette commande écoute sur TCP 5201. Ouvrez le port uniquement pour l’adresse depuis laquelle vous effectuez le test, puis refermez-le à la fin. Règles de base du pare-feu ufw sur un VPS explique la syntaxe.

Depuis le VPS testé :

iperf3 -c 203.0.113.10 -t 30
iperf3 -c 203.0.113.10 -t 30 -R
iperf3 -c 203.0.113.10 -t 30 -P 8

La première commande mesure le débit montant depuis la machine testée. -R inverse le sens et mesure le débit descendant. -P 8 ouvre huit flux parallèles.

Exécutez à la fois le test avec un seul flux et la version parallèle. Ils répondent à des questions différentes. Une connexion TCP ne peut contenir qu’une quantité de données non acquittées limitée par sa fenêtre. Son plafond correspond donc approximativement à la taille de la fenêtre divisée par le temps aller-retour. Avec une latence de 80 ms et une fenêtre de 4 MB, ce plafond est d’environ 400 Mbit/s, quelle que soit la vitesse de la liaison sous-jacente. Le résultat avec un seul flux indique le débit obtenu par un téléchargement unique. Le résultat avec plusieurs flux indique la capacité de la liaison.

Surveillez votre quota de bande passante pendant le test. Trente secondes à 1 Gbit/s représentent environ 3.75 GB de données, et vous exécuterez le test plusieurs fois dans chaque sens.

Chiffres de référence et lecture de vos résultats

[
  {
    "device": "Local NVMe",
    "iops_4k_read": "180,000"
  },
  {
    "device": "Local SATA SSD",
    "iops_4k_read": "90,000"
  },
  {
    "device": "Network block",
    "iops_4k_read": "12,000"
  },
  {
    "device": "Spinning disk",
    "iops_4k_read": "180"
  }
]

Un volume NVMe local atteint généralement environ 180,000 IOPS en lecture aléatoire 4k dans les résultats publiés. Un SSD SATA local se situe autour de 90,000. Le stockage bloc attaché au réseau, pour lequel chaque requête traverse le réseau avant d’atteindre un disque, se rapproche plutôt de 12,000, tandis qu’un disque dur mécanique atteint environ 180, car il déplace une tête physique pour chaque requête aléatoire.

Il s’agit de chiffres publiés typiques pour chaque classe de stockage, et non de mesures réalisées sur un seul hôte. Utilisez-les uniquement pour vérifier que votre propre résultat se situe dans le bon ordre de grandeur. Si une offre présentée comme du NVMe obtient quelques milliers d’IOPS en lecture aléatoire 4k lors du benchmark, vérifiez d’abord que --direct=1 était activé. Si c’était le cas, soit le stockage ne correspond pas à la description de la page produit, soit vous le partagez avec un voisin très sollicité.

Pourquoi un seul test ne constitue pas une référence

Un résultat unique est un instantané d’une minute sur une machine partagée. Considérez-le comme un seul échantillon.

• Exécutez chaque test au moins cinq fois, à des heures différentes et sur au moins deux jours différents. Conservez la médiane et la dispersion. Un résultat publié sans dispersion est une valeur marketing.
• Relevez le steal time à côté de chaque exécution. Écartez les exécutions où st était élevé ou, au minimum, indiquez-le.
• Exécutez le test du disque avec deux durées. De nombreuses offres fournissent un quota d’IOPS en rafale qui se reconstitue avec le temps. Une exécution de fio pendant 60 secondes mesure la rafale, tandis que --runtime=600 mesure le débit plancher. Le plancher correspond aux performances obtenues les mauvais jours.
• Vérifiez qu’aucune autre tâche ne s’exécute. Le démarrage de unattended-upgrades d’une transaction apt au milieu d’un test CPU vous fait perdre des points réels, et ps -e -o comm= | grep -E 'apt|dpkg' avant chaque exécution ne prend qu’une seconde.
• Ne modifiez qu’une variable à la fois. Des versions différentes des outils, des tailles de blocs différentes ou un nombre de threads différent produisent des valeurs qui ne sont pas comparables, même si elles semblent similaires.

Lorsque vous comparez deux fournisseurs, exécutez les tests à la même heure le même jour. Sinon, vous mesurez l’heure de la journée.

Évaluez votre propre charge en dernier

Les outils synthétiques classent les machines. Seule votre propre charge indique si une machine est suffisante. Mesurez le temps de l’opération que vous effectuez réellement.

time tar -czf /tmp/bench.tgz /usr/share
rm -f /tmp/bench.tgz

Cette commande compresse quelques centaines de mégaoctets. Elle sollicite donc à la fois le processeur et le disque, et son résultat varie dès que l’un des deux change. L’avertissement Removing leading / from member names est normal. Mieux encore, mesurez le temps de votre propre build, de votre requête la plus lente ou du rendu de votre propre page. Un build qui prend 4 minutes sur un hôte et 7 sur un autre répond à la question, quel que soit le résultat de Geekbench. C’est aussi la mesure qui vous indique à partir de quel moment une machine plus puissante ne justifie plus son coût. Il est utile de le savoir avant de lire ce que coûte réellement un VPS par mois ou de déplacer la charge sur un serveur dédié.

FAQ

Pourquoi le résultat du benchmark est-il différent à chaque exécution ?

Un VPS partage le processeur, le stockage et le réseau physiques avec d’autres utilisateurs. Votre résultat dépend donc de leur activité à cet instant. Exécutez vmstat 1 pendant le test et consultez la colonne st : un steal time maintenu au-dessus de 5 indique que l’hôte était chargé. Votre score CPU est alors faible pour des raisons extérieures à votre machine. La solution consiste à utiliser une méthode cohérente, pas à ajuster le système. Exécutez chaque test au moins cinq fois, à différentes heures, puis indiquez la médiane avec la dispersion des résultats.

Pourquoi fio indique-t-il des millions d’IOPS ?

C’est presque toujours parce que --direct=1 est absent. Sans cette option, fio lit via le page cache du kernel. Après le premier passage, un fichier de test de 2G est donc servi depuis la RAM, et vous mesurez la bande passante mémoire. Ajoutez --direct=1 et utilisez un fichier de test plus grand que tous les caches présents sur le chemin. Si --direct=1 échoue alors avec err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, exécutez df -hT . : un Type de overlay ne prend pas en charge O_DIRECT. Dirigez donc le test vers un stockage réel.

yabs.sh suffit-il à lui seul ?

Pour un premier aperçu, oui. Il exécute fio avec quatre tailles de blocs, iperf3 dans les deux directions et Geekbench. Il affiche ensuite un récapitulatif que d’autres personnes peuvent lire. Il ne suffit plus lorsque vous voulez comprendre l’origine d’un résultat, car vous ne pouvez pas faire varier ses options pour chaque test. Dès qu’un résultat yabs semble incorrect, reproduisez-le directement avec fio ou sysbench et ne modifiez qu’une option à la fois.

Quel chiffre unique permet de prévoir les performances ressenties par mon application ?

Pour la plupart des charges web et des bases de données, la vitesse sur un seul cœur CPU, puis la latence des lectures aléatoires en 4k, dans cet ordre. Les chiffres de débit sont impressionnants, mais ils déterminent rarement le résultat, car une requête classique est de petite taille. Indiquez le 99e percentile du bloc clat percentiles de fio plutôt que la moyenne. La requête lente sur 100 est celle que l’utilisateur remarque.

Dois-je installer quelque chose avant de lancer un benchmark ?

fio, sysbench et iperf3 sont disponibles dans les dépôts Ubuntu et Debian : sudo apt install -y fio sysbench iperf3. yabs.sh nécessite seulement curl, car il télécharge des binaires statiques pour les éléments manquants. Supprimez tous les fichiers de test à la fin. Un fichier fio de 2G laissé sur un disque de 20G peut sinon déclencher plusieurs semaines plus tard une alerte de disque plein.