Méthodologie de benchmark

Le processus de benchmark

Un benchmark complet se lance avec /bench start, par un joueur connecté au serveur. Le plugin enchaîne 16 tests en trois phases, dont 14 forment le score (voir Comment fonctionne le scoring) :

1. Matériel — disk, network et memory, pendant que la JVM chauffe
2. Gameplay — des charges Minecraft : chunkLoading, hopper, worldSave, explosion, redstone, blockPhysics, chunkTicking, lightingUpdate, tickingTileEntity, mobAI, boneMealGrowth
3. CPU — singleCoreBenchmark puis multiCore, en dernier, une fois la JVM bien chaude

Le plugin fait le reste tout seul : il fait apparaître les entités, charge les chunks, actionne la redstone, déclenche les explosions, puis nettoie et envoie le rapport. En détail :

• Avant le run, il vérifie que la commande vient d'un joueur connecté, qu'aucun autre test ne tourne et que le délai local entre deux benchmarks (30 minutes par défaut) est écoulé. Des vérifications préalables cherchent ensuite les risques — un monde cible qui n'est pas plat ou pas un monde voxelbench_*, d'autres joueurs en ligne, un serveur déjà chargé (TPS sous 19 ou MSPT au-dessus de 30 ms), un hébergement gratuit, des plugins susceptibles d'interférer — et les listent sur un écran où vous confirmez ou annulez.
• La JVM chauffe pendant 30 secondes avant le premier test.
• Chaque test tourne avec des paramètres fixes en mode standard (benchmark-mode: standard, le mode par défaut) : chaque serveur exécute la même charge.
• Les tests de gameplay ignorent leurs 5 premières secondes d'échantillons, et le plugin marque une pause entre deux tests, le temps que les chunks du précédent se déchargent.
• Un test ignoré ou échoué n'arrête pas le run, mais le rapport n'a alors pas de score.
• Le run se déroule dans un monde de benchmark : le monde épinglé si vous en avez défini un, sinon un monde plat temporaire (voxelbench_temp_…) créé pour le run et supprimé ensuite. Sur Folia, qui ne peut pas créer de monde en cours de route, épinglez-en un.

Les étapes vues depuis le serveur sont dans Benchmarks, et les mondes dans Mondes de benchmark.

Durée du test

Un benchmark complet dure en général de 10 à 15 minutes. Les serveurs plus rapides terminent les tests plus vite — c'est en soi un indicateur de performance, et la durée totale du run, chauffe comprise, entre dans le score : un run de 5 minutes ou moins vaut ×1,15, le multiplicateur est neutre vers 13 minutes, puis descend à ×0,90 à 20 minutes et à ×0,70 à 40 (voir Durée). Chaque test a aussi une durée limite : un test qui ne progresse plus ou dépasse son plafond est arrêté, et compte comme échoué.

Plusieurs runs

/bench start <runs> enchaîne de 1 à 20 benchmarks, à 10 secondes d'intervalle, chacun avec son rapport ; /bench start warmup ajoute un premier run dont les résultats sont écartés. Plusieurs runs montrent de combien vos résultats varient d'un run à l'autre (voir Mode multi-run).

Préparer un benchmark fiable

Obtenir des résultats réguliers et comparables demande de maîtriser l'environnement de test. Voici une liste de contrôle.

Configuration du serveur

Version Minecraft

• Utilisez une version stable (ni snapshot ni pré-version)
• Comparez des résultats obtenus sur la même version de Minecraft
• Les nouvelles versions peuvent avoir d'autres caractéristiques de performance

Logiciel serveur

• Paper est recommandé pour les résultats les plus optimisés
• Spigot, Purpur et Folia sont pris en charge, et les serveurs hybrides sont détectés, avec quelques limites (voir Compatibilité)
• Des résultats obtenus avec des logiciels serveur différents ne se comparent pas directement

Version Java

• La version de Minecraft fixe le minimum : Java 16 ou 17 pour la 1.17, 17 de la 1.18 à la 1.20.4, 21 de la 1.20.5 à la 1.21, 25 pour les 26.x (voir Prérequis Java)
• Utilisez la version de Java la plus récente que votre version de Minecraft accepte, et la même pour comparer

Arguments JVM (critique)

La configuration du garbage collector a un impact majeur sur les résultats : ses pauses arrêtent le fil principal, et apparaissent comme des ticks lents dans les 95e et 99e centiles de la durée des ticks, qui pèsent le plus dans le score.

• Les flags d'Aikar sont la base recommandée pour la plupart des serveurs
• G1GC (par défaut avec les flags d'Aikar) offre un bon équilibre entre débit et latence
• ZGC (-XX:+UseZGC) produit des pauses très courtes mais peut consommer plus de mémoire
• Évitez les flags JVM par défaut sans réglage — ils entraînent de longues pauses GC

Réglages JVM à vérifier :

• -Xms et -Xmx doivent être égaux (évite le redimensionnement du tas pendant les tests)
• Donnez au serveur assez de mémoire pour les tests les plus lourds : avant chaque test, le plugin estime son pic de mémoire et ignore un test qui risquerait d'épuiser le tas, et un rapport qui contient un test ignoré n'a pas de score
• Ne surdimensionnez pas : un tas bien plus grand que nécessaire peut allonger les pauses GC

Environnement

Aucun autre joueur

• Lancez les benchmarks sans autre joueur en ligne que celui qui les démarre ; les vérifications préalables signalent les autres joueurs
• L'activité des joueurs crée une charge imprévisible qui varie d'un run à l'autre
• Même des joueurs AFK génèrent des ticks de chunks et des interactions d'entités
• Restez connecté jusqu'à la fin : certains tests ont besoin de vous, et sont ignorés si vous partez

Pas d'autres plugins (idéal)

• Pour la comparaison matérielle la plus juste, testez avec le seul plugin VoxelBench
• Si vous devez tester votre configuration de production, sachez que les autres plugins ajoutent de la charge
• Les vérifications préalables nomment les plugins les plus susceptibles d'interférer (protection de monde comme WorldGuard, GriefPrevention, Towny ou Lands, profileurs comme spark, et Essentials)

Ressources dédiées

• Fermez les autres applications de la machine (ou de la VM ou du conteneur)
• En hébergement mutualisé : les serveurs des autres clients influencent vos résultats
• Le bridage du CPU (modes d'économie d'énergie, bridage thermique) produit des résultats irréguliers
• Si possible, lancez le benchmark aux heures creuses de la machine hôte

État du monde

• Laissez le benchmark tourner dans un monde de benchmark : un monde voxelbench_* épinglé (/bench world create, puis /bench world set) ou le monde plat temporaire
• Votre propre carte ne joue alors aucun rôle dans les résultats : le terrain est plat et les zones de test sont construites pour le run

Réseau

• La latence entre votre serveur et voxelbench.com n'affecte pas le score : toutes les mesures sont prises sur le serveur
• Le test network mesure la vitesse à laquelle le serveur sérialise les données de jeu (NBT), pas votre connexion, et ne pèse rien
• La connexion doit seulement être assez stable pour envoyer le rapport

Ce qui rend les résultats comparables

Deux benchmarks sont directement comparables quand :

Un run unique n'est qu'un échantillon : comparez plusieurs runs de chaque serveur avant de conclure.

Comparaison d'hébergeurs

Les pages Hébergeurs et le catalogue des Offres montrent, pour chaque offre, sa preuve la plus forte. La plus forte est un résultat certifié : VoxelBench achète l'offre comme n'importe quel client, la benchmarke trois fois — des runs d'auto-bench espacés d'au moins une heure, ou des runs retenus par un modérateur — et en garde le run médian, vérifie que la machine correspond aux caractéristiques annoncées (un écart se conclut par un rejet), et publie le rapport une fois que l'hébergeur l'a approuvé. L'hébergeur peut contester un résultat avant de l'approuver. Voir Certification et Comparer les hébergeurs.

La charge est ainsi la même que sur votre propre serveur — les mêmes tests standard avec les mêmes paramètres, dans un monde de benchmark plat — et ce qui change, c'est l'infrastructure de l'hébergeur elle-même : CPU, mémoire, E/S disque, et la qualité de l'isolation des ressources par rapport aux autres clients.

Facteurs qui nuisent à votre score

Facteurs qui n'affectent PAS votre score