Comment bien benchmarker un VPS avec yabs.sh

Ce que signifie l’évaluation des performances d’un VPS

Pour évaluer les performances d’un VPS, vous mesurez quatre éléments : la vitesse d’exécution d’un seul cœur CPU, la bande passante mémoire disponible sur la machine, le nombre d’opérations disque aléatoires de petite taille que le stockage peut traiter chaque seconde, et le débit fourni par la liaison réseau. Une exécution de yabs.sh vous donne ces quatre mesures en environ dix minutes. L’interprétation du résultat est plus difficile, car un VPS (virtual private server) 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.

L’objectif est d’exécuter yabs.sh pour obtenir une vue d’ensemble rapide, puis d’exécuter manuellement les outils utilisés en arrière-plan. Les exécuter vous-même vous permet de modifier un flag, d’observer l’évolution de la valeur et de comprendre ce que cette valeur mesurait réellement. Faites-le une fois la machine configurée, et non avant. Les étapes décrites dans les dix premières minutes sur un nouveau VPS viennent d’abord, car une machine qui applique encore sa première série de mises à jour obtient de mauvais résultats de benchmark pour des raisons sans rapport avec le matériel.

Examinez la machine avant de la mesurer

La moitié de chaque benchmark erroné provient d’une machine que son auteur ne comprenait pas.

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

Hypervisor vendor: KVM signifie une virtualisation complète : vous exécutez donc votre propre kernel. L’affichage de lxc ou de openvz par systemd-detect-virt signifie 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), et non par du matériel virtuel. Sur un système cgroup v2, vous pouvez lire directement la limite de CPU.

cat /sys/fs/cgroup/cpu.max

max 100000 signifie qu’aucun quota n’est défini. 200000 100000 signifie que vous pouvez utiliser 200000 microsecondes de CPU sur chaque période de 100000 microsecondes, soit un quota équivalent à deux cœurs. Une offre annoncée à 4 vCPU avec un quota de deux cœurs n’obtiendra jamais les mêmes résultats qu’avec quatre cœurs, et aucun outil de benchmark n’affiche une ligne vous 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

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 à un autre utilisateur. C’est le signal unique le plus utile pour déterminer si un résultat vient 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 supérieures à 5 maintenues dans le temps indiquent que l’hôte est en situation de surallocation à ce moment-là. Tous les chiffres CPU relevés pendant cette période sont donc faibles, sans que votre machine soit en cause. top affiche la même valeur que %st sur la ligne CPU. Laissez vmstat 1 s’exécuter dans une deuxième session SSH pendant vos benchmarks et notez la valeur du steal à côté de chaque résultat.

Commencer 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écapitulatif. 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.

Le projet utilise cette commande sur une seule ligne.

curl -sL yabs.sh | bash

Cette commande envoie directement au shell le contenu actuellement fourni par l’URL. Téléchargez-le, 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

Vous devez connaître deux éléments avant la première exécution. Geekbench téléverse votre résultat et affiche une URL publique browser.geekbench.com. Toute personne disposant de ce lien peut donc consulter votre modèle de 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 disque exécute fio avec une répartition de 50/50 entre les lectures et les écritures, selon quatre tailles de bloc : 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 la plus importante 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 sur un serveur 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 avec des serveurs publics situés dans plusieurs régions, dans les deux directions, en utilisant des flux parallèles. Considérez ici un résultat faible comme un élément à vérifier, et non comme une conclusion, car les serveurs publics iperf3 sont partagés et souvent saturés. Le mauvais résultat peut donc venir de l’autre extrémité.

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 surtout combien de cores vous avez réellement obtenus.

Disque : exécuter 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 le rôle des options.

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

Voici un test de lecture aléatoire en 4k, avec une profondeur de file 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 ressemble à ceci.

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

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

• --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 disposant 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 concerne la mémoire.
• --ioengine=libaio soumet des requêtes asynchrones. Cela permet à --iodepth=32 d’en maintenir 32 en cours. Avec un moteur synchrone comme psync, une profondeur de file supérieure à 1 ne sert à rien : vous mesurez une seule requête à la fois.
• --time_based --runtime=60 exécute le test pendant une durée fixe de 60 secondes, au lieu de traiter 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. Gardez-la supérieure à la taille de tout cache présent sur le chemin, et vérifiez d’abord que vous disposez de suffisamment d’espace libre.

L’écriture aléatoire utilise la même commande avec --rw=randwrite. Exécutez-la 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 utiliser 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 SATA SSD sur un VPS.

Lorsque 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 terminer, 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, définissez --filename sur 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

Soyez précis sur ce que mesure cette exécution. Après le premier passage, le fichier de 256M se trouve dans le page cache. La valeur d’IOPS décrit donc votre RAM. Utilisez-la pour vérifier que fio est installé et que les flags sont correctement interprétés. Ne la présentez jamais comme un résultat disque.

Pourquoi dd n’est pas un benchmark de disque

dd apparaît dans de nombreuses discussions 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 de cohérence raisonnable. Elle ne dit rien sur les E/S aléatoires ni sur ce qui se passe lorsque 32 requêtes arrivent simultanément. Supprimez oflag=direct et elle mesure principalement la vitesse à laquelle votre kernel accepte les écritures en mémoire. C’est pourquoi les valeurs de dd citées dans les messages des 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 sur un seul thread. Cette valeur détermine la rapidité avec laquelle une requête PHP se termine ou une tâche de compilation s’achève. C’est aussi la valeur qui varie le plus entre des hôtes proposés au même prix. Lancez ensuite le test avec tous les threads. Cela indique si vos vCPU correspondent à des cœurs distincts ou à des portions de cœurs.

Précisez ce que mesure ce test : sysbench cpu recherche de manière répétée des nombres premiers avec une arithmétique entière sur 64 bits. Il ne sollicite pas la bande passante mémoire, les unités vectorielles ou le cache d’une manière comparable à une charge réelle. Il convient donc pour classer deux hôtes, mais pas pour prédire 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 contenant --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 dont la version n’est pas indiquée.

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, et les lectures sont plus rapides que les écritures sur toutes les machines. Gardez --memory-block-size à 1M et utilisez exactement la même valeur sur chaque hôte comparé. Avec 1K, le résultat s’effondre, car le surcoût par opération intervient 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 configurée différemment dans les scores mémoire publiés.

Réseau : iperf3

La méthode fiable pour tester le débit consiste à utiliser une seconde 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 fermez-le à la fin. La page Règles de base du pare-feu ufw sur un VPS présente 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 version à flux unique et la version parallèle. Elles répondent à des questions différentes. Une connexion TCP ne peut maintenir qu’une quantité de données non acquittées limitée par la taille de sa fenêtre. Son débit maximal est donc approximativement égal à 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 débit maximal est d’environ 400 Mbit/s, quelle que soit la vitesse de la liaison sous-jacente. La valeur obtenue avec un flux unique indique le débit d’un téléchargement. La valeur obtenue avec plusieurs flux indique la capacité de la liaison.

Surveillez votre quota de bande passante pendant ces tests. Trente secondes à 1 Gbit/s transfèrent environ 3.75 GB, et vous exécuterez le test plusieurs fois dans chaque sens.

Chiffres de référence et interprétation 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, où chaque requête traverse le réseau avant d’atteindre un disque, se situe plutôt autour de 12,000, tandis qu’un disque rotatif 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 catégorie de stockage, et non de mesures effectuées sur un même 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, 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 seul résultat 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, à différentes heures et sur au moins deux jours différents. Conservez la médiane et la dispersion. Un résultat publié sans dispersion est une donnée marketing.
• Notez 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 nombreux forfaits accordent une réserve d’IOPS burst qui se reconstitue avec le temps. Une exécution de fio de 60 secondes mesure le burst, tandis que --runtime=600 mesure le niveau minimal. C’est ce niveau que vous obtenez les mauvais jours.
• Vérifiez qu’aucun autre processus ne s’exécute. unattended-upgrades qui démarre 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 des nombres de threads différents 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 de travail en dernier

Les outils synthétiques classent les machines. Seule votre propre charge de travail vous 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 CPU et le disque, et son résultat change dès que l’un des deux évolue. 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 permet de trancher, 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 de travail vers un serveur dédié.

FAQ

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

Un VPS partage le CPU, le stockage et le réseau physiques avec d'autres locataires. Votre résultat dépend donc de leur activité à ce moment-là. Exécutez vmstat 1 pendant le test et lisez la colonne st : un steal time soutenu supérieur à 5 indique que l'hôte était chargé. Votre score CPU est alors faible pour des raisons extérieures à votre machine. La solution consiste à appliquer une méthode plutôt qu'à ajuster la configuration. Exécutez chaque test au moins cinq fois, à différentes heures, puis indiquez la médiane avec la dispersion.

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

La cause est presque toujours l'absence de --direct=1. 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 faites en sorte que le fichier de test soit plus grand que tout cache présent sur le chemin. Si --direct=1 échoue ensuite 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 le stockage réel.

yabs.sh suffit-il à lui seul ?

Pour un premier aperçu, oui. Il exécute fio avec quatre tailles de bloc, iperf3 dans les deux directions et Geekbench. Il affiche aussi un récapitulatif que d'autres personnes peuvent lire. Il ne suffit plus lorsque vous voulez comprendre l'origine d'une valeur, car vous ne pouvez pas modifier les flags pour chaque test. Lorsqu'un résultat yabs semble incorrect, reproduisez-le directement avec fio ou sysbench et ne modifiez qu'un flag à la fois.

Quel nombre unique prédit les performances ressenties par mon application ?

Pour la plupart des charges web et des bases de données, la vitesse CPU sur un seul cœur et la latence de lecture aléatoire 4k sont les indicateurs les plus importants, dans cet ordre. Les valeurs de débit sont impressionnantes, mais déterminent rarement les performances, car une requête typique est petite. Indiquez le 99e percentile du bloc clat percentiles de fio plutôt que la moyenne. La requête lente sur cent est celle que l'utilisateur remarque.

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

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