Benchmarker un VPS sans sélectionner seulement l’exécution la plus rapide
Un benchmark utile répond à une question de charge définie et fournit assez de détails sur l’environnement, les commandes, les sorties brutes et les horaires pour être reproduit. Un score isolé et inexpliqué ne représente ni toutes les applications ni les performances futures d’une infrastructure partagée.
Points clés
- Unité minimale de publication
- Question, environnement, commande, durée, répétitions, date et sortie brute
- Règle de comparaison
- Même configuration VPS, image, version d’outil et fenêtre de test
- Synthèse honnête
- Conserver exécutions lentes et échouées ; publier médiane et variabilité
- Limite de sécurité
- Limiter l’usage des ressources et respecter les règles du fournisseur et du réseau
Commencer par une question liée à la charge
Décidez quelle décision le résultat doit éclairer. Compilation CPU, API sensible à la latence, base transactionnelle, sauvegarde séquentielle et service de fichiers multi-utilisateur sollicitent des ressources différentes. Choisissez un test ressemblant à l’accès réel et définissez le seuil de réussite avant les résultats afin de ne pas promouvoir le chiffre le plus élevé.
Précisez offre et région, durée, concurrence, volume de données, mélange lecture-écriture, taille de blocs, protocole, endpoint distant et plage horaire. Les hôtes partagés et routes Internet varient : un benchmark est un échantillon daté sous conditions déclarées, pas une garantie permanente.
- Écrivez la décision et le seuil avant de commencer.
- Testez si possible une transaction au niveau applicatif.
- Ne fusionnez pas des scores sans rapport en une note opaque.
Consigner assez de contexte pour reproduire l’exécution
Relevez offre, région, heure de provisionnement, image système, noyau, présentation CPU, mémoire, swap, périphériques de stockage, système de fichiers, options de montage, famille IP et versions des outils. Les commandes utiles incluent lscpu, free -h, lsblk et uname -r. Retirez secrets clients et identifiants uniques avant publication.
Indiquez si le serveur vient d’être provisionné, préchauffé, redimensionné ou exécute une autre charge. Consignez le début dans un fuseau clair et les maintenances du fournisseur. Pour le réseau, identifiez les deux endpoints, leurs réseaux, la direction, le protocole et les limites de débit. Une simple paire de villes n’est pas reproductible.
- Figez les versions des outils ou conservez les métadonnées des paquets.
- Maintenez le même état système entre comparaisons.
- Publiez les exceptions importantes au lieu de relancer silencieusement.
Exécuter des tests CPU, stockage et réseau limités
Pour le CPU, choisissez un outil comme sysbench avec nombre de threads et durée déclarés. Pour le stockage, fio peut modéliser accès séquentiel ou aléatoire, profondeur de file, taille de bloc, E/S directes, taille de fichier et mélange lecture-écriture ; sauvegardez la sortie exploitable avec --output-format=json. Dimensionnez le fichier pour la question et expliquez les effets du cache.
Pour la capacité réseau, iperf3 exige un endpoint distant contrôlé et des limites de temps et débit. Testez les deux directions si pertinent. Pour le délai, ping échantillonne temps aller-retour et pertes, mais indiquez source, cible, intervalle, nombre, famille d’adresses et conditions du chemin. Les tests intensifs peuvent gêner les voisins ou déclencher des limites : obtenez l’autorisation et arrêtez si la santé du service se dégrade.
- Utilisez un VPS de test dédié sans charge client.
- Répétez la même séquence au moins cinq fois pour une comparaison publiée.
- Conservez sortie, erreurs et code de fin de chaque exécution.
Résumer la variabilité au lieu de la masquer
Examinez chaque exécution pour erreurs, limitation, pression mémoire, stockage plein, activité en arrière-plan et saturation de l’endpoint. Ne supprimez pas un résultat lent parce qu’il dérange. Si une exécution est invalide, conservez-la, expliquez la règle d’exclusion et reprenez toute la séquence prévue plutôt que de choisir opportunément une valeur de remplacement.
Publiez la médiane du comportement central répété et une plage ou un percentile montrant la variation. Pour le stockage, incluez latence et débit ou opérations par seconde. Pour le réseau, incluez pertes et limites de l’endpoint. Ne comparez que des configurations matériellement équivalentes et signalez les différences.
- Distinguez les exécutions invalides de celles valides mais lentes.
- Affichez unités et méthodes d’agrégation avec chaque valeur.
- Évitez les pourcentages fondés sur des environnements incomparables.
Publier ensemble méthode, données brutes et limites
Une page de preuve crédible relie une méthode versionnée, un manifeste d’environnement, les commandes exactes, les fichiers bruts individuels, un tableau de synthèse, la date et la personne responsable. Utilisez des noms stables et des sommes de contrôle si possible. Précisez que les résultats décrivent l’échantillon testé et peuvent varier avec allocation matérielle, contention, routage, logiciel ou politique du fournisseur.
Recommencez après toute évolution importante d’infrastructure ou d’image et conservez les anciens résultats avec leur date d’origine. Les corrections doivent rester visibles. Le modèle de transparence de VPSEverywhere.com reste exclu de l’indexation tant qu’il contient des valeurs d’exemple ; seules de vraies mesures validées selon le processus annoncé doivent devenir des preuves opérationnelles.
- Publiez les exécutions échouées et lentes dans le dossier brut.
- Datez et versionnez chaque révision de la méthode.
- N’inventez jamais rétroactivement des mesures non effectuées.
Sources
Questions fréquentes
Quel benchmark VPS est le meilleur ?
Aucun benchmark unique n’est supérieur partout. Choisissez des tests ressemblant à la charge et publiez leur configuration. Les mesures applicatives répondent souvent mieux à une décision d’achat qu’un score synthétique.
Combien d’exécutions dois-je publier ?
Cette méthode utilise au moins cinq exécutions identiques et conserve chaque résultat valide. Davantage d’échantillons peuvent être nécessaires si la variabilité est forte ou la décision importante.
Pourquoi publier la médiane plutôt que le meilleur résultat ?
Le maximum favorise la sélection opportuniste. La médiane décrit le centre des observations répétées ; une plage ou un percentile montre la variabilité. Aucun ne garantit les performances futures.
Puis-je exécuter `fio` ou `iperf3` sur un serveur de production ?
Évitez les tests perturbateurs sur des charges clients. Utilisez un environnement dédié, limitez durée et débit, respectez les règles du fournisseur et vérifiez que l’endpoint distant est autorisé et ne constitue pas le goulot.