Comment bien benchmarker un VPS

Ce que signifie l’analyse comparative d’un VPS

Pour analyser un VPS, vous mesurez quatre éléments : la vitesse d’exécution d’un seul cœur de processeur, la bande passante mémoire disponible, 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 fournit des résultats pour le processeur, le disque et le réseau en environ dix minutes ; utilisez le test mémoire séparé ci-dessous pour mesurer la bande passante mémoire. L’interprétation des résultats 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.

L’objectif est d’exécuter yabs.sh pour obtenir rapidement une première vue, puis de lancer manuellement les outils utilisés. Les exécuter vous-même vous permet de modifier un flag, d’observer l’évolution de la valeur et de comprendre ce qu’elle mesure réellement. Faites-le une fois la machine configurée, pas avant. Commencez par suivre les étapes décrites dans les dix premières minutes sur un nouveau VPS, car une machine qui installe encore sa première série de mises à jour produit de mauvais résultats pour des raisons qui n’ont rien à voir avec le matériel.

Observez la machine avant de la mesurer

La moitié des mauvais benchmarks provient 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 exécutez donc votre propre kernel. L’affichage de systemd-detect-virt ou de lxc ou openvz 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), pas par du matériel virtuel. Sur un système cgroup v2, vous pouvez lire la limite CPU depuis le cgroup de votre conteneur. Le chemin suivant s’applique lorsque ce cgroup est monté dans /sys/fs/cgroup.

cat /sys/fs/cgroup/cpu.max

max 100000 signifie que ce cgroup n’a pas de quota propre ; des cgroups parents peuvent tout de même en imposer un. 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 avec 4 vCPU et un quota de deux cœurs n’obtiendra jamais les mêmes résultats qu’une machine à quatre cœurs. Les outils de benchmark peuvent détecter cette restriction : VoxelBench indique les quotas CPU et signale un CPU partagé ou bridé lorsque l’hôte expose bien plus de CPU que le serveur ne peut en utiliser.

df -hT / est important pour une autre raison : la colonne Type. Si sa valeur est overlay, vous êtes dans un conteneur, et vos résultats disque décriront le stockage sous-jacent à cette couche overlay. 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 a attendu involontairement parce que l’hyperviseur ne l’a pas planifié. C’est un indicateur utile du temps CPU indisponible, mais il ne permet pas de distinguer des voisins gourmands d’une limitation de quota CPU appliquée par le fournisseur.

vmstat 1 10

Lisez la colonne st à droite. Un steal time élevé et constant signifie que du temps CPU était indisponible pour le guest, mais une valeur supérieure à 5% ne prouve pas que l’hôte est surchargé. Les fournisseurs peuvent exposer délibérément l’application d’un quota CPU sous la forme de steal time. 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, 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 exécute fio, iperf3 et Geekbench, puis affiche un récapitulatif unique. Il utilise fio et iperf3 s’ils sont déjà installés et télécharge des binaires statiques dans le cas contraire. C’est le langage commun des échanges consacrés aux 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 au shell le contenu fourni aujourd’hui 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 flags 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 à trois le nombre de sites 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 le premier lancement. Geekbench téléverse votre résultat et affiche une URL publique browser.geekbench.com. Toute personne qui possè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 au volume.

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. Lorsque fio échoue dès sa première requête avec --direct=1 activé, il faut donc commencer par écarter les E/S directes. L’échec peut se présenter ainsi :

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 .. Un Type de overlay, le système de fichiers que Docker fournit par défaut à un conteneur, n’est pas la cause à lui seul. overlayfs transmet O_DIRECT au système de fichiers sous-jacent et le refuse uniquement lorsque celui-ci ne prend pas en charge les E/S directes. Ainsi, --direct=1 --ioengine=libaio fonctionne sur une couche overlay reposant sur ext4 ou xfs. Lorsque le système de fichiers sous-jacent au fichier de test ne prend réellement pas en charge les E/S directes, fio l’indique généralement lors de l’ouverture du fichier : fio: looks like your file system does not support direct=1/buffered=0. Dans ce cas, dirigez --filename vers un chemin situé sur un stockage local réel, par exemple un volume monté par bind mount, ou exécutez fio sur l’hôte plutôt que dans le conteneur. Si le stockage réel est inaccessible, une exécution synchrone avec mise en mémoire tampon 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 des IOPS décrit donc votre RAM. Utilisez-la pour vérifier que fio est installé et que les options sont correctement analysées. Ne la présentez jamais comme un résultat de disque.

Pourquoi dd n’est pas un benchmark de disque

dd est souvent cité dans les discussions sur les VPS, mais il ne répond qu’à 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 attente. C’est un contrôle de cohérence raisonnable. Elle ne dit rien sur les E/S aléatoires, ni sur le comportement du système lorsque 32 requêtes arrivent simultanément. Supprimez oflag=direct et les écritures passent par le cache de pages, mais conv=fdatasync force toujours l’écriture des données de sortie sur le stockage avant la fin de la commande. Supprimez également cette option, et le résultat peut surtout mesurer la vitesse à laquelle votre noyau accepte les écritures en mémoire. C’est pourquoi les valeurs de dd citées dans les messages de forum 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. C’est ce qui détermine la rapidité d’exécution d’une requête PHP ou d’une tâche de compilation. C’est aussi la valeur qui varie le plus entre des hôtes au même prix. Lancez ensuite le test avec tous les threads. Vous verrez ainsi comment le débit évolue sur l’ensemble de vos vCPU alloués.

Précisez ce que ce test mesure : sysbench cpu recherche en boucle des nombres premiers par division successive. Pour chaque candidat, il calcule une racine carrée en double précision, puis teste les diviseurs avec une opération modulo sur des entiers 64 bits. Chaque diviseur est comparé à cette limite en virgule flottante. Le test combine donc des opérations sur des entiers et en virgule flottante. Il ne sollicite pas la bande passante mémoire, les unités vectorielles ou 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é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 reprenez dans un ancien article une commande avec --test=cpu, 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. Conservez --memory-block-size à 1M et utilisez exactement la même valeur sur tous les hôtes comparés. À 1K, le débit s’effondre, car le surcoût par 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 incohé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.

Valeurs 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 vers 12,000, tandis qu’un disque mécanique atteint environ 180, car il déplace une tête physique pour chaque requête aléatoire.

Il s’agit de valeurs publiées typiques pour chaque catégorie de stockage, et non de mesures effectué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, vérifiez d’abord que --direct=1 était activé. Si c’était le cas, contrôlez les limites d’IOPS et les crédits de burst de l’offre, ainsi que la contention sur le stockage et le matériel annoncé.

Pourquoi une seule exécution ne constitue pas un benchmark

Un seul résultat est un instantané d’une minute sur une machine partagée. Considérez-le comme un é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 un chiffre marketing.
• Notez le steal time à côté de chaque exécution. Conservez les exécutions où st était élevé et vérifiez si cela reflète une contention ou le quota CPU du plan ; les supprimer peut masquer les performances que vous obtenez réellement.
• Exécutez le test disque avec deux durées. De nombreux plans fournissent une réserve d’IOPS burst qui se reconstitue au fil du temps, mais ni une exécution fio de 60 secondes ni --runtime=600 ne garantissent que vous avez mesuré le niveau minimal. Les crédits AWS gp2 peuvent maintenir 3,000 IOPS pendant au moins 30 minutes à partir d’un solde plein ; les deux exécutions peuvent donc mesurer les performances burst. Vérifiez le modèle de crédits du fournisseur et surveillez le solde de crédits avant de considérer un résultat comme une performance soutenue.
• Vérifiez qu’aucun autre processus ne s’exécute. unattended-upgrades démarrer 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 ou des nombres de threads produisent des chiffres qui ne sont pas comparables, même s’ils semblent similaires.

Lorsque vous comparez deux fournisseurs, exécutez les tests à la même heure du même jour. Sinon, vous avez mesuré 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 change-t-il à chaque exécution ?

Un VPS partage le CPU, le stockage et le réseau physiques avec d’autres clients. Votre résultat dépend donc de ce qu’ils font à ce moment-là. Exécutez vmstat 1 pendant le test et consultez la colonne st : un steal time élevé indique du temps CPU indisponible, mais peut aussi refléter l’application par le fournisseur de la capacité CPU souscrite, et pas seulement la contention sur l’hôte. Une valeur supérieure à 5% ne permet pas d’en déterminer la cause. La bonne approche consiste à répéter les mesures plutôt qu’à ajuster la configuration. Exécutez chaque test au moins cinq fois à différentes heures, puis indiquez la médiane et la dispersion.

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

Presque toujours parce que --direct=1 est absent. Sans cette option, fio lit via le page cache du noyau. 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 veillez à ce que le fichier de test soit plus grand que tout cache présent sur le chemin. Si --direct=1 échoue ensuite, exécutez df -hT . et vérifiez sur quel support se trouve le fichier de test. Un type overlay n’est pas un problème en soi, car overlayfs transmet O_DIRECT au stockage sous-jacent. Déplacez le fichier de test vers un stockage local réel uniquement si le système de fichiers sous-jacent refuse les accès directs.

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, puis affiche un résumé 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 de yabs semble incorrect, reproduisez-le directement avec fio ou sysbench et modifiez une seule option à la fois.

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

La vitesse d’un seul cœur CPU, puis la latence des lectures aléatoires en 4k, dans cet ordre, pour la plupart des charges web et des bases de données. Les chiffres de débit sont impressionnants, mais déterminent rarement le résultat, car une requête typique est de petite taille. Indiquez le 99e percentile du bloc clat percentiles de fio plutôt que la moyenne : c’est la requête lente sur cent 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 s’exécute dans Bash et nécessite curl ou wget pour les téléchargements, ainsi que tar pour extraire Geekbench. Sans tar, il ignore Geekbench. Il utilise fio et iperf3 lorsqu’ils sont installés et télécharge des binaires statiques lorsqu’ils sont absents. Supprimez tous les fichiers de test à la fin, car un fichier fio de 2G laissé sur un disque de 20G finira par déclencher l’alerte de disque plein de quelqu’un quelques semaines plus tard.