Comparaison de serveur VPS : benchmark fio, sysbench et iperf3
Pour comparer deux VPS sur des mesures et non sur des fiches commerciales, appliquez le même protocole aux deux machines : mêmes paramètres, mêmes conditions, plusieurs passes. Mesurez le disque avec fio, le CPU et la RAM avec sysbench, le réseau avec iperf3, et relevez le steal time pendant chaque test.
Ce protocole tient en cinq étapes, à répéter sur trois passes à des heures différentes pour chaque machine. Il complète un guide pour choisir un VPS pour développeurs, qui traite des usages plutôt que des mesures.
En bref
- Une comparaison objective repose sur trois règles : mêmes paramètres, mêmes conditions, plusieurs mesures.
- Les deux VPS ont le même OS, le même noyau, le même nombre de vCPU et la même RAM.
- Trois passes à des heures différentes, et on retient la médiane.
- fio en accès direct mesure les IOPS et la latence, sysbench le CPU et la mémoire, iperf3 le réseau.
- Le steal time (voir le lexique de l'hébergement) se relève pendant chaque test : c'est lui qui trahit la sur-allocation.
Préparer un protocole reproductible
Commencez par figer tout ce qui peut varier : même distribution (Ubuntu 24.04 LTS ou Debian 12), mêmes vCPU, même RAM, VPS fraîchement installé, aucun service actif. Ne lancez jamais ces tests sur une machine en production, car fio écrit en continu et sature le disque.
sudo apt update
sudo DEBIAN_FRONTEND=noninteractive apt install -y fio sysbench iperf3 sysstat mtr-tiny
lscpu | grep "Model name"
uname -r
Les tests fio s'exécutent sur un fichier de test, jamais sur le périphérique brut (/dev/vda) : vous risqueriez de détruire des données. Sur Windows Server, les outils et les tests diffèrent, voir les critères pour comparer un VPS Windows Server.
Recopiez ce relevé pour chaque passe :
| Champ | À noter |
|---|---|
| Date et heure | ex. mardi 21 h |
| Modèle CPU, vCPU, RAM | sortie de lscpu |
| Noyau et versions | uname -r, fio --version, sysbench --version, iperf3 --version |
| Résultats | IOPS, p99, events/s, %steal, Mbit/s |
Mesurer les IOPS et la latence disque avec fio
Les trois commandes ci-dessous reprennent les paramètres décrits dans la documentation officielle de fio. --direct=1 contourne le cache de pages du système : sans lui, vous mesureriez la RAM. libaio est le moteur d'E/S asynchrone natif de Linux, et io_uring en est une alternative récente. Peu importe lequel vous choisissez, gardez le même sur tous les VPS.
# 1. Lecture aléatoire 4k
fio --name=randread --filename=/var/tmp/fio-test --rw=randread --bs=4k \
--iodepth=32 --numjobs=1 --direct=1 --ioengine=libaio --size=4G \
--runtime=60 --time_based --group_reporting
# 2. Écriture aléatoire 4k
fio --name=randwrite --filename=/var/tmp/fio-test --rw=randwrite --bs=4k \
--iodepth=32 --numjobs=1 --direct=1 --ioengine=libaio --size=4G \
--runtime=60 --time_based --group_reporting
# 3. Séquentiel 1M (lecture et écriture, débit en Mo/s)
fio --name=seq --filename=/var/tmp/fio-test --rw=rw --bs=1M \
--iodepth=8 --numjobs=1 --direct=1 --ioengine=libaio --size=4G \
--runtime=60 --time_based --group_reporting
rm /var/tmp/fio-test
Pourquoi 60 secondes et 4 Go ? Beaucoup de VPS autorisent un burst : des IOPS élevés pendant quelques dizaines de secondes, puis un plafond. Un test de 10 secondes mesure ce burst, pas la performance tenue dans la durée. Si votre RAM dépasse 4 Go, augmentez --size au-delà de la RAM.
Dans la sortie, lisez IOPS, bw (débit) et surtout les percentiles de clat (latence de complétion) : p99 et p99.9. Une latence p99 instable pèse plus lourd qu'un pic d'IOPS, parce que c'est elle que ressentent une base de données ou un serveur de jeu.
Tester le CPU et la mémoire avec sysbench
Le test CPU de sysbench calcule des nombres premiers jusqu'à --cpu-max-prime, dont la valeur par défaut est 10000. Nous prenons 20000. Quelle que soit votre valeur, gardez-la identique partout : les scores ne se comparent pas d'une valeur à l'autre.
sysbench cpu --cpu-max-prime=20000 --threads=1 --time=30 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) --time=30 run
sysbench memory --memory-block-size=1M --memory-total-size=10G run
Relevez events per second. Le calcul utile est le rapport entre le score multi-thread et le score mono-thread multiplié par le nombre de vCPU. Proche de 1, les vCPU sont réellement disponibles. Nettement en dessous (notre règle de travail : moins de 0,7), ils sont partagés ou bridés.
Il n'existe pas de score « normal » universel, puisqu'il dépend de la génération de CPU, d'où le lscpu. Comparez deux VPS équipés du même modèle de processeur. Sinon, l'écart reflète le matériel, pas la sur-allocation.
Mesurer le débit réseau avec iperf3
iperf3 fonctionne en client/serveur. Sur la machine distante, lancez iperf3 -s. Selon le manuel d'iperf3, le serveur écoute par défaut sur le port TCP 5201. Ouvrez-le dans le pare-feu pour la seule IP du client, puis refermez-le après le test.
sudo ufw allow from IP_CLIENT to any port 5201
iperf3 -s # côté serveur
iperf3 -c IP_SERVEUR -t 30 -P 4 # TCP, 4 flux parallèles
iperf3 -c IP_SERVEUR -t 30 -P 4 -R # sens inverse
iperf3 -c IP_SERVEUR -u -b 500M -t 30 # UDP : gigue et perte
En UDP, l'option -b est indispensable : le débit cible par défaut n'est que de 1 Mbit/s. Ce mode intéresse surtout le gaming et la VoIP, où la gigue et la perte comptent plus que le débit brut.
Un résultat proche du débit nominal du port, une fois déduit le surcoût des en-têtes TCP/IP, est sain. Sur un port 1 Gbit/s, cela donne environ 940 Mbit/s (calcul à partir de la taille des trames Ethernet). Le débit dépend aussi du chemin réseau et de la machine distante. Utilisez donc deux VPS de votre propre parc plutôt qu'un serveur public peut-être saturé. Pour la latence, complétez avec ping et mtr depuis la zone géographique de vos utilisateurs.
Détecter le steal time et la sur-allocation
Le steal time correspond au temps pendant lequel votre vCPU est prête à tourner mais attend que l'hyperviseur lui donne un cœur physique. Le noyau le comptabilise dans /proc/stat, décrit dans la documentation du noyau Linux. Vous le lirez dans la colonne %st de top, %steal de mpstat et st de vmstat. À la source, c'est le 8e champ de la ligne cpu de /proc/stat, soit $9 avec awk, puisque $1 est le mot « cpu ».
La méthode : lancez sysbench en continu et relevez le steal en parallèle. Comme /proc/stat donne des compteurs cumulés depuis le démarrage, notez la valeur avant et après le test : seule la différence reflète le steal du test.
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) --time=120 run &
mpstat -P ALL 5 20
awk '/^cpu /{print "steal (ticks) =", $9}' /proc/stat
Trois signaux trahissent une sur-allocation : un steal soutenu au-delà de quelques pour cent (on cite souvent 5 à 10 %), une forte variance entre passes ou selon l'heure, et des IOPS qui s'effondrent après le burst. Si ces signaux persistent malgré un changement de plan, ou si votre charge dépasse ce qu'un VPS peut offrir, regardez de près le passage d'un VPS à un serveur dédié. Une virtualisation KVM à ressources dédiées limite ce phénomène.
Tableau de résultats types et seuils d'interprétation
Ces valeurs sont des ordres de grandeur et des règles de décision de travail, à confronter à vos propres mesures. Elles ne constituent pas une promesse commerciale.
| Test | Indicateur | Valeur saine | Signal d'alerte |
|---|---|---|---|
| fio randread 4k | IOPS, latence p99 | IOPS stables sur 60 s, proches du plafond annoncé ; p99 du même ordre que la médiane | Écart de plus de 20 % entre passes ; p99 dix fois supérieur à la médiane |
| fio randwrite 4k | IOPS, latence p99 | Idem, avec des écritures plus lentes que les lectures | Effondrement après le burst |
| fio séquentiel 1M | Mo/s | Débit constant, stable d'une passe à l'autre | Chute de moitié en cours de test |
| sysbench 1 thread et N threads | events/s | Rapport multi/(mono × N) proche de 1 | Rapport inférieur à 0,7 |
| Steal | %st / %steal | Proche de 0 % | Plus de 5 % soutenus |
| iperf3 TCP | Mbit/s | Proche du nominal moins le surcoût (≈ 940 sur 1 Gbit/s) | Débit très variable ou sous 70 % du nominal |
| iperf3 UDP | Gigue, perte | Perte nulle, gigue très faible | Perte récurrente, gigue de plusieurs ms |
Notre règle de décision : à prix proche, choisissez la stabilité (faible variance, steal proche de 0), pas le pic.
Les erreurs qui faussent une comparaison
- Un test unique, alors qu'il en faut au moins trois.
- L'oubli de
--direct=1. - Un fichier de test trop petit, qui mesure le cache.
- Des VPS avec un nombre de vCPU différent.
- Un test iperf3 vers un serveur saturé.
- Un test lancé pendant une mise à jour du système.
- La lecture de la moyenne au lieu des percentiles.
Choisir un VPS sur des critères mesurables
Avant de tester, exigez par écrit le type de virtualisation (KVM), la politique de sur-allocation, le débit du port réseau, le type de stockage, la localisation du datacenter (latence vers la France, RGPD) et la protection Anti-DDoS. Un hébergeur qui refuse de répondre sur la sur-allocation vous a déjà répondu.
Notre offre VPS Linux haute performance coche ces critères : virtualisation KVM sans sur-allocation, stockage SSD, réseau 10 Gbit/s avec peering France-IX, hébergement au datacenter Telehouse Paris (Tier 3+), Anti-DDoS 1 Tbit/s inclus, sans engagement. Elle peut donc passer par le même protocole. Les offres sont en pré-commande, avec une disponibilité annoncée au 1er novembre 2026 : nous ne publions aucun score tant que nous n'avons rien mesuré.
Questions fréquentes
Comment comparer objectivement les performances de deux VPS ?
Utilisez le même OS, le même noyau, les mêmes vCPU et la même RAM, puis lancez les mêmes commandes fio, sysbench et iperf3. Faites trois passes à des heures différentes et comparez les médianes, pas les meilleurs résultats.
Comment mesurer les IOPS d'un VPS avec fio ?
Lancez fio avec --rw=randread --bs=4k --iodepth=32 --direct=1 --ioengine=libaio --runtime=60 --time_based sur un fichier de test de 4 Go. Lisez la ligne IOPS et les percentiles p99 et p99.9 de clat.
Quel score sysbench CPU est normal pour un VPS ?
Il n'y a pas de score universel : il dépend du modèle de CPU et de la valeur de --cpu-max-prime (10000 par défaut). Comparez deux VPS avec le même processeur et les mêmes paramètres, et vérifiez que le score multi-thread approche le score mono-thread multiplié par le nombre de vCPU.
Comment détecter le steal time et la sur-allocation sur un VPS ?
Lancez sysbench cpu en continu et lisez %st dans top ou %steal dans mpstat -P ALL 5. Un steal soutenu au-dessus de 5 % (certains retiennent 10 %), ou qui varie fortement selon l'heure, signale une sur-allocation.
Comment tester le débit réseau d'un VPS avec iperf3 ?
Lancez iperf3 -s sur une machine, puis iperf3 -c IP -t 30 -P 4 sur l'autre. Ajoutez -R pour le sens inverse. Le port 5201 doit être ouvert dans le pare-feu.
Combien de fois faut-il lancer un benchmark pour qu'il soit fiable ?
Trois passes au minimum, à des heures différentes (par exemple matin, après-midi et soirée), en retenant la médiane. Si l'écart entre passes dépasse 20 %, le VPS est instable : ajoutez des passes avant de conclure.
Lancer le protocole sur votre prochain VPS
Recopiez le tableau de relevé et lancez la première passe sur votre VPS actuel : vous aurez une référence chiffrée avant de comparer quoi que ce soit. Pré-commandez ensuite votre VPS Linux haute performance et testez-le avec ce protocole dès sa disponibilité, le 1er novembre 2026.