Benchmarks

Comment fonctionnent les benchmarks

Un benchmark VoxelBench mesure les performances de votre serveur Minecraft à travers une série de tests automatisés. Chaque test simule un type de charge précis et mesure la façon dont votre matériel et votre logiciel serveur y font face.

Déroulement d'un benchmark

Ce qui se passe après /bench start :

1. Contrôles : la commande doit venir d'un joueur connecté, aucun autre test ne doit tourner, et le cooldown local entre deux benchmarks doit être écoulé (30 minutes par défaut).
2. Vérifications préalables (sauf si confirmation.require-confirmation vaut false) : VoxelBench recherche les risques : monde épinglé non plat ou qui n'est pas un monde voxelbench_*, aucun monde épinglé alors que benchmark.auto-temp-world vaut false, autres joueurs connectés, serveur déjà chargé, hébergement gratuit détecté, plugins susceptibles d'interférer. Sans monde épinglé, le run utilise un monde plat temporaire, qui n'est pas vérifié. S'il trouve un risque, un écran d'inventaire les liste et vous demande de confirmer (voir Mondes de benchmark).
3. Préparation : dans tous les mondes chargés, la météo est dégagée et l'heure réglée sur midi, cycle jour/nuit arrêté. Sur Paper et Spigot, les mobs, animaux, villageois, golems, objets au sol, projectiles, wagonnets et bateaux des mondes voxelbench_* sont retirés ; rien n'est retiré d'aucun autre monde, ni sur Folia (voir Garde-fous). Puis les zones de test sont générées, et la position et le mode de jeu du joueur sont sauvegardés.
4. Phase 1 - Matériel : disque, réseau et mémoire, pendant que la JVM chauffe.
5. Phase 2 - Gameplay : charges Minecraft (chunks, hoppers, explosions, redstone, entités...).
6. Phase 3 - CPU : single-core puis multi-core, en dernier, une fois la JVM entièrement chauffée.
7. Rapport : le rapport est sauvegardé localement, puis envoyé à voxelbench.com, qui calcule le score ; le score s'affiche dans le chat et est inscrit dans le rapport local.
8. Nettoyage : les blocs et entités créés par les tests sont supprimés, la météo et le cycle jour/nuit de chaque monde reviennent tels qu'ils étaient (l'horloge n'est pas remontée), et le joueur est restauré.

Pendant un benchmark

• Vous pouvez être déplacé vers les zones de test ; vous êtes ramené ensuite
• Le serveur subit du lag pendant les tests intensifs : c'est normal
• Une barre de progression et un scoreboard affichent le test en cours et l'avancement global
• /bench stop interrompt le run : le test en cours retire ce qu'il a fait apparaître, et la météo et le cycle jour/nuit sont rendus. Rien d'autre n'est retiré hors des mondes voxelbench_*
• Les animaux, villageois et objets de vos propres mondes restent en place : hors des mondes voxelbench_*, VoxelBench ne retire que ce que ses tests ont fait apparaître

Catalogue des tests

VoxelBench embarque 26 tests intégrés, répartis en trois catégories. Des extensions peuvent en ajouter d'autres (voir Créer une extension). Chaque test peut être lancé seul avec /bench test <id> ; la dernière colonne indique ceux que lance le /bench start standard.

Matériel

CPU single-core

La performance mono-thread est le principal facteur limitant d'un serveur Minecraft.

Gameplay

Certains tests nécessitent un joueur connecté et ne peuvent pas être lancés depuis la console ; voir Commandes.

Dans quel monde tourne /bench test

Tous les tests de gameplay sauf worldSave écrivent dans le monde : ils construisent puis vident des zones de test loin du spawn, font apparaître des mobs, ou génèrent des chunks qui restent dans les fichiers du monde. /bench test ne les lance donc jamais dans le monde où vous vous trouvez :

• si un monde est épinglé avec /bench world set, ils y tournent, et y construisent puis y vident leurs zones de test. playerWorldLoad, qui casse des blocs naturels autour de x=0, z=0 et jusqu'à 8 000 blocs de là, rend à chaque bloc modifié son état d'origine à la fin (orientation et moitiés de porte comprises), et ne touche jamais aux blocs à contenu (coffres, spawners, panneaux, lits) ;
• sinon, /bench test crée un monde plat temporaire (voxelbench_temp_<horodatage>), même si vous êtes dans le monde principal, et le supprime à la fin, y compris après un échec ou un /bench stop. Sa création prend quelques secondes par test : épinglez un monde (par exemple créé avec /bench world create) pour vous en passer ;
• si aucun monde temporaire ne peut être créé (benchmark.auto-temp-world: false, ou création échouée), le test est refusé au lieu de se rabattre sur le monde principal.

Les tests matériels et CPU et worldSave (une sauvegarde du monde tel qu'il est) n'écrivent pas dans le monde : ils tournent toujours dans le monde épinglé, ou dans celui où vous vous trouvez.

Les tests qui ont besoin de vous sur place (mobAI, villagerTrading, mobPathfinding, entityCollision, liquidPhysics, combatSimulation) emmènent le joueur qui les a lancés dans leur zone, en mode spectateur, et le ramènent là où il était, dans son mode de jeu, quand le test se termine, échoue ou est arrêté, comme le fait /bench start. Si vous vous déconnectez pendant le test, vous êtes renvoyé à votre place au moment où vous partez, et vous vous reconnectez là où vous étiez (sur Folia, vous êtes ramené juste après votre connexion suivante) ; de même si le serveur s'arrête pendant le test. mobSpawn fait apparaître ses mobs dans des zones dispersées sans vous déplacer, et les tests headless (hopper, lightingUpdate, chunkTicking…) ne déplacent personne : ils gardent leurs chunks chargés avec des tickets.

Sur Folia, on ne peut pas créer de monde pendant que le serveur tourne : ces tests exigent donc un monde épinglé, et sont refusés sans lui. Seul un monde que le serveur charge au démarrage peut y être épinglé ; épingler votre monde principal, c'est accepter que ces tests y construisent et y vident leurs zones, comme /bench start le fait sur Folia.

Seul /bench test suit cette règle : la commande, le GUI des tests, et les jobs d'auto-bench en mode test. /bench start, /bench stresslimit, /bench tier et les profils personnalisés suivent toujours le monde épinglé, puis benchmark.auto-temp-world, et ne perdent aucun test. Un profil de benchmark personnalisé suit d'abord son propre options.auto-temp-world, qui peut désactiver le monde temporaire, mais pas l'activer (voir Profils personnalisés). Seule exception : dans un profil personnalisé, une étape playerWorldLoad hors du monde épinglé ou d'un monde voxelbench_* est esquivée avec le motif benchmark_world_required.

Dans un monde temporaire, le terrain est plat : les résultats ne dépendent plus de votre carte. Ils correspondent à ce que /bench start mesure dans son propre monde temporaire, mais ne sont pas comparables aux /bench test précédents faits dans votre propre monde (notamment chunkLoading, qui y générait du vrai terrain).

VoxelScore

Après un benchmark complet, votre serveur reçoit un VoxelScore, un nombre unique qui résume ses performances globales. Le score est calculé par voxelbench.com à partir des résultats envoyés, pas par le plugin. Le plugin affiche ce que renvoie le backend :

• le VoxelScore total et un rang
• trois sous-scores par catégorie : Single-Core (40 %), Gameplay (40 %) et Matériel (20 %)
• un bonus de synergie

Les sous-scores ne suivent pas les catégories du catalogue des tests ci-dessus. Sur voxelbench.com, Single-Core se compose de redstone et blockPhysics ; Matériel, de memory, disk et multiCore ; Gameplay, de chunkLoading, chunkTicking, lightingUpdate, mobAI, hopper, explosion, tickingTileEntity, worldSave et boneMealGrowth. network, singleCoreBenchmark et singleCoreMax ne comptent dans aucun sous-score. Les écrans de score de /bench gui le disent : ils listent sous Single-Core les tests que le site y compte, et marquent network et singleCoreBenchmark Non compté dans le score du site (voir Rapports).

Les règles de calcul et les seuils de rang sont définis sur voxelbench.com et peuvent évoluer. Les runs de profils personnalisés sont conservés par le backend mais ne reçoivent pas de VoxelScore.

Mode standard vs custom

Mode standard (par défaut)

benchmark-mode: standard

Tous les paramètres de test sont fixes pour que les résultats restent comparables d'un serveur à l'autre. /bench start exécute les 16 tests marqués « Oui » ci-dessus.

Mode custom

benchmark-mode: custom

/bench start lit plusieurs paramètres de test dans config.yml au lieu d'utiliser les valeurs fixes, et la phase gameplay exécute en plus mobSpawn, entityCollision, liquidPhysics et combatSimulation. Le rapport est marqué comme un run en mode custom. Voir Configuration.

Mode multi-run

Pour des résultats plus fiables, lancez plusieurs benchmarks d'affilée :

/bench start 5
/bench start warmup 3

La première commande lance 5 benchmarks. Avec warmup, un benchmark supplémentaire tourne d'abord et ses résultats sont écartés. Avant le premier run, les chunks autour des zones de test sont préchargés ; chaque run réutilise les mêmes zones, et les runs sont espacés de 10 secondes. Dans un monde voxelbench_*, les régions de test sont réinitialisées entre deux runs ; dans tout autre monde, rien n'est supprimé. Voir Commandes.

Bonnes pratiques pour des résultats précis :

• Lancez 3 à 5 benchmarks et comparez
• Assurez-vous que le serveur est au repos (pas de joueurs, pas de fermes actives)
• Utilisez le mode standard pour des résultats comparables
• Benchmarkez dans un monde plat dédié (/bench world create, puis /bench world set)

Profils personnalisés

Un profil personnalisé est un fichier YAML qui décrit votre propre benchmark : quels tests, dans quel ordre, avec quels paramètres. Les profils se trouvent dans plugins/VoxelBench/custom_benchmarks/. VoxelBench y copie ses profils fournis à la création du dossier, puis une fois chaque profil ajouté par une version ultérieure. Un profil fourni que vous supprimez ne revient pas (le fichier .bundled-profiles du dossier s'en souvient). Une copie non modifiée d'une ancienne version est remplacée par la version courante ; une copie que vous avez modifiée n'est jamais touchée.

Un profil de benchmark ressemble à ceci :

name: "Storage Suite"
description: "Disque et génération de chunks"
author: "vous"
version: 1
tags: [storage]
submit: false          # false (défaut) = non envoyé à voxelbench.com

tests:
  - id: disk
    params:
      threads: 4
      fileSizeMb: 1024
  - id: chunkLoading
    params:
      chunksToLoad: 200
      dispersedZones: 4

• kind: choisit le type de profil : benchmark (défaut) ou stresslimit (voir Stress Limit). S'il est absent, un fichier qui contient une section stress: sans section tests: est traité comme un profil de stress.
• Un id de test inconnu fait rejeter tout le profil au chargement ; un paramètre hors limites est ramené dans la plage autorisée, avec un avertissement.
• Avec submit: true, le run est envoyé à voxelbench.com en tant que run de profil personnalisé : privé au départ, jamais noté ni classé.

Commandes :

/bench custom list
/bench custom info storage-suite
/bench custom run storage-suite
/bench custom reload

Le nom du profil est le nom du fichier sans .yml. /bench custom run doit être lancé en jeu, nécessite un serveur lié (même avec submit: false) et partage le cooldown de /bench start. Les profils n'exécutent pour l'instant qu'une seule itération. Profils personnalisés en donne la référence complète : chaque clé, les paramètres de chaque test, la validation et l'empreinte du profil.

Comparer les résultats

Rendez-vous sur voxelbench.com pour :

• Comparer votre serveur avec d'autres ayant un matériel similaire
• Suivre les performances dans le temps
• Identifier les goulots d'étranglement dans des catégories de tests précises
• Partager vos résultats avec votre communauté

Vous pouvez aussi parcourir et comparer les rapports locaux en jeu (/bench reports, voir Rapports).

Sous Folia, le TPS et le MSPT de lightingUpdate, tickingTileEntity et playerWorldLoad mesurés par VoxelBench 2.0.2 et les versions antérieures ne suivaient pas les régions où ces tests travaillaient : ne les comparez qu'avec des résultats de versions ultérieures (voir Support Folia).