Profils personnalisés

Les profils se trouvent dans plugins/VoxelBench/custom_benchmarks/ et se lancent avec /bench custom run <nom>.

Cette page en est la référence complète ; Benchmarks en donne un aperçu. Ne confondez pas les profils personnalisés avec benchmark-mode: custom dans config.yml, qui change ce que lance /bench start (voir Benchmarks).

Démarrage rapide

/bench custom list
/bench custom info standard
/bench custom run standard

1. /bench custom list affiche les profils chargés, marqués [STD] (benchmark) ou [STRESS] (stress limit).
2. /bench custom info standard affiche le détail d'un profil et ses étapes.
3. /bench custom run standard le lance. La commande doit être tapée en jeu par un joueur, et le serveur doit être lié à un compte voxelbench.com, même si le profil n'envoie rien.
4. Pour écrire le vôtre, copiez standard.yml en mon-profil.yml dans le même dossier et modifiez la copie : donnez-lui son propre name:, puis changez les étapes. Lancez /bench custom reload, puis /bench custom run mon-profil. Inutile de redémarrer.

Profils fournis

VoxelBench fournit neuf profils :

Mises à jour et profils supprimés

• VoxelBench copie chaque profil fourni une seule fois : tous à la création du dossier, puis un profil ajouté par une version ultérieure (comme hopper-heavy.yml) au premier démarrage après la mise à jour.
• Le fichier .bundled-profiles du dossier liste les profils déjà copiés : un profil fourni que vous supprimez ne revient donc pas. Pour en retrouver un, retirez son nom de .bundled-profiles et lancez /bench custom reload.
• À chaque lecture du dossier (au démarrage et au rechargement), une copie identique à une ancienne version d'un profil fourni, fins de ligne mises à part, est remplacée par la version courante, et la console le signale. Une copie que vous avez modifiée, ne serait-ce que d'un caractère, n'est jamais touchée. Pour garder vos modifications tout en recevant les mises à jour de l'original, travaillez sur une copie sous un autre nom.

Fichiers de profil

• Un profil est un fichier .yml ou .yaml placé dans plugins/VoxelBench/custom_benchmarks/.
• Son nom est celui du fichier, sans l'extension et en minuscules : Mon-Profil.yml se lance avec /bench custom run mon-profil. Deux fichiers dont les noms ne diffèrent que par la casse ou l'extension portent le même nom, et un seul des deux est chargé.
• Un même dossier accueille les deux types. La clé kind:, au premier niveau, les distingue : benchmark (par défaut) ou stresslimit. Sans kind:, un fichier qui a une section stress: et pas de section tests: est un profil de stress limit ; tout autre fichier est un profil de benchmark. Toute valeur de kind: autre que stresslimit (quelle que soit la casse) est lue comme benchmark.

Clés communes

Ces clés sont facultatives et fonctionnent de la même façon dans les deux types :

Les autres clés de premier niveau sont ignorées.

Profils de benchmark

kind: benchmark                # facultatif : benchmark est le défaut
name: "Redstone et chunks"
description: "Horloges redstone, puis génération de chunks"
author: "VotreNom"
version: 1
tags: [redstone, chunks]
submit: false                  # true = envoyer le rapport à voxelbench.com

options:
  auto-temp-world: true        # false = tourner dans le monde principal (voir Monde de test)

tests:
  - id: disk
    params:
      threads: 4
      fileSizeMb: 1024
  - id: redstone
    params:
      pistonCount: 3200
      durationSeconds: 60
  - id: chunkLoading
    params:
      chunksToLoad: 1000
      dispersedZones: 8        # plus de 1 = les 8 zones du run
  - id: worldSave              # aucun paramètre
  - id: singleCoreBenchmark
    params:
      durationSeconds: 30

options: n'a qu'un réglage, auto-temp-world (voir Monde de test). Les autres clés placées sous options: n'ont aucun effet, mais elles comptent dans l'empreinte du profil.

Étapes

• tests: est la liste des étapes. Chaque entrée est une table avec un id: et, au besoin, des params:.
• Les étapes s'exécutent dans l'ordre où elles sont écrites, l'une après l'autre. Les profils fournis placent les tests matériels en premier, les tests gameplay ensuite et les tests CPU en dernier : c'est l'ordre qui donne les mesures les plus fiables.
• id: est un identifiant de test : l'un des 26 tests intégrés, ou un test ajouté par une extension. La casse, - et _ ne comptent pas : chunkLoading, chunk-loading et CHUNK_LOADING désignent le même test. /bench test list liste tous les tests que connaît le serveur, ceux des extensions compris.
• Les noms courts que /bench test accepte aussi (lighting, collision, tileentity, villager) ne sont pas des identifiants de test : dans un profil, écrivez lightingUpdate, entityCollision, tickingTileEntity et villagerTrading.

Paramètres

Dans un profil, chaque paramètre s'écrit par son nom sous params:, alors que /bench test prend pour beaucoup de tests des valeurs simples dans un ordre fixe (voir Commandes). Un paramètre omis prend sa valeur par défaut. Un nombre hors de la plage autorisée est ramené à la borne la plus proche au lancement du run, avec un avertissement.

* Plafonné aussi par config.yml, sans avertissement : voir Réglages lus dans config.yml.

• kernel (tests CPU) vaut int, float, memory ou branch. Toute autre valeur lance int, sans avertissement.
• type (tickingTileEntity) vaut FURNACE, HOPPER, SPAWNER ou ALL. Toute autre valeur lance ALL, avec un avertissement.
• Écrivez les nombres en entiers simples (50000000). Une valeur qui n'est pas un nombre est remplacée par le défaut, avec un avertissement.
• Pour chunkLoading, mobSpawn, hopper et explosion, dispersedZones ne choisit qu'entre une zone et huit. Chaque run de profil dispose 8 zones de test éloignées les unes des autres, comme /bench start. Un tel test avec dispersedZones: 1, ou sans dispersedZones, tourne dans une seule zone ; avec une valeur de 2 à 10, il tourne dans les 8 zones du run. Écrivez 8 pour le rendre explicite. lightingUpdate et tickingTileEntity utilisent le nombre de zones que vous écrivez.
• chunkLoading reste sous un plafond mémoire : 30 % du tas maximal, à environ 50 Ko par chunk, partagés entre les zones que le test parcourt réellement (les 8 zones du run pour toute valeur de dispersedZones supérieure à 1, une seule zone sinon), sans jamais descendre sous 200 chunks par zone. Avec 8 zones, chaque zone reçoit au plus 0,75 chunk par Mo de tas maximal : chunksToLoad: 1000 est réduit sur un tas de moins de 1 330 Mo environ. Avant VoxelBench 2.0.3, le plafond était divisé par la valeur de dispersedZones écrite dans le profil : un profil en dispersedZones: 2 pouvait charger jusqu'à quatre fois le plafond sur un petit tas, et ses anciens runs ne se comparent pas aux nouveaux sur un tel serveur.
• Les tests ajoutés par des extensions déclarent leurs propres paramètres : reportez-vous à la documentation de l'extension.

Le profil fourni showcase.yml reprend chaque paramètre avec un court commentaire, et standard.yml contient les valeurs de /bench start.

Monde de test

Un profil de benchmark choisit son monde ainsi :

1. Un monde épinglé avec /bench world set est toujours utilisé, s'il est chargé. S'il ne l'est pas, vous recevez un avertissement et les règles suivantes s'appliquent.
2. Sinon, quand options.auto-temp-world vaut true (sa valeur par défaut est celle de benchmark.auto-temp-world dans config.yml), le run crée un monde plat temporaire, voxelbench_temp_<horodatage>, et le supprime à la fin. Cela n'arrive que si benchmark.auto-temp-world vaut aussi true dans config.yml : un profil peut désactiver le monde temporaire, pas l'activer. Si le monde ne peut pas être créé, le run se replie sur le monde principal et la console le signale.
3. Sinon, les tests tournent dans le monde principal du serveur (le premier qu'il charge) : ils y construisent et y vident leurs zones de test.

playerWorldLoad ne tourne que dans le monde épinglé ou dans un monde voxelbench_*. Partout ailleurs, l'étape est sautée avec la raison benchmark_world_required et le reste du run continue. Voir aussi Configuration et Benchmarks.

Réglages lus dans config.yml

Un profil ne contient pas tous les réglages de ses tests. Quelques-uns sont lus dans le config.yml du serveur à chaque run (voir Configuration) :

• benchmark-tests.chunk-loading.limits, benchmark-tests.mob-spawn.limits et benchmark-tests.explosion.limits plafonnent chunksToLoad, mobCount et tntCount, sans avertissement. Avec le config.yml livré, cela fait au plus 5 000 chunks, 1 000 mobs et 200 TNT, même si le tableau ci-dessus autorise davantage.
• benchmark-tests.chunk-loading.adaptive (régulation de la génération de chunks), benchmark-tests.hopper.hopper-chain-length, benchmark-tests.mob-spawn.duration-seconds et benchmark-tests.explosion.raise-host-tnt-quota s'appliquent aussi.
• benchmark-tests.hopper.limits ne s'applique pas : il ne borne que la commande /bench test hopper. Un profil exécute les lignes qu'il demande, jusqu'à 500 par zone.

Deux serveurs qui lancent le même profil n'exécutent donc la même charge que si ces réglages sont identiques.

Profils de stress limit

Un profil de stress limit lance le mode Stress Limit avec votre propre recette : quels types de stress pousser, à partir de quelle charge, jusqu'à quel plafond, et à partir de quand un palier est considéré comme rompu.

kind: stresslimit
name: "Contrôle des fermes"
description: "Hoppers et mobs, seuil de rupture plus strict"
author: "VotreNom"
version: 1
tags: [fermes]
submit: false

stress:
  types:
    - id: hoppers
      base: 100          # charge de départ
      max: 4000          # plafond souple
    - id: mobs           # ni base ni max : les bornes nominales du type
  thresholds:
    tpsBreak: 19.0
    msptBreak: 50.0
  timing:
    palierDurationSec: 12
  zones: 2

stress.types est la seule clé obligatoire. Chaque entrée est une table avec un id:, parmi mobs, chunks, hoppers, tnt, redstone, entities et villagers (voir Types de stress). Les types s'exécutent dans l'ordre où ils sont écrits ; un type cité deux fois ne s'exécute qu'une fois.

• base est la charge de départ et max le plafond souple. Si vous en omettez un, il garde la valeur nominale du type. Une base supérieure à max est ramenée à max.
• Le plafond souple continue de monter tant que le serveur a de la marge, jusqu'au plafond dur du type, égal à cinq fois son plafond nominal. Un max au-delà de ce plafond y est ramené : aucun profil ne peut le relever.

Toutes les autres clés sont facultatives et gardent la valeur qu'utilise /bench stresslimit :

Les seuils décident du résultat ; la montée, la recherche et les durées décident de la vitesse et de la précision avec lesquelles on le trouve. VoxelBench ne vérifie pas la plage de ces nombres : restez proche des valeurs des profils fournis. Le fonctionnement des paliers, de la montée et de la recherche est expliqué dans Mode Stress Limit.

Un profil de stress limit n'a pas d'options:. Il utilise le monde épinglé, sinon un monde temporaire si benchmark.auto-temp-world vaut true, sinon le monde principal, comme /bench stresslimit. Il part de la mémoire du démarrage à chaud et la met à jour, comme un run stress limit complet. Contrairement à /bench stresslimit, il démarre sans demander de confirmation.

Commandes

Toutes les commandes /bench custom exigent voxelbench.custom ou voxelbench.start (réservés aux opérateurs par défaut) ; reload exige aussi voxelbench.reload, et lancer un profil de stress limit exige aussi voxelbench.stresslimit, comme /bench stresslimit. /bench reload ne relit pas les profils. L'auto-complétion propose les noms des profils chargés après info, et après run seulement les profils que vous pouvez lancer : les profils de stress limit uniquement avec voxelbench.stresslimit. La liste des profils disponibles affichée après un nom inconnu suit la même règle ; list et info montrent tous les profils.

/bench custom run :

• doit être tapée par un joueur en jeu, pas depuis la console ;
• exige un serveur lié, même quand le profil a submit: false ;
• est refusée pendant un autre test ou run, et /bench stop l'arrête ;
• partage le cooldown de /bench start (voir Configuration). force ignore le cooldown si vous avez voxelbench.start.force ;
• démarre aussitôt, sans confirmation ;
• n'exécute qu'une itération : warmup et un nombre de runs sont acceptés, mais un message vous indique qu'ils ne s'appliquent pas aux profils.

Un run est enregistré dans vos rapports locaux (/bench reports), parmi les benchmarks standard pour un profil de benchmark et parmi les rapports Stress Limit pour un profil de stress limit, sauf si config.yml désactive ce type de rapport. Voir Rapports.

Voir aussi Commandes.

Depuis l'interface

/bench gui, puis l'onglet Tests, puis Profils personnalisés, liste les profils chargés que vous pouvez lancer : une étoile du Nether signale un profil de benchmark, de la TNT un profil de stress limit (affiché seulement avec voxelbench.stresslimit). L'écran exige voxelbench.custom ou voxelbench.start. Un clic sur un profil lance /bench custom run <nom>, avec les mêmes contrôles. Le bouton d'actualisation lance /bench custom reload, qui exige voxelbench.reload.

Validation

Au chargement

VoxelBench lit le dossier au démarrage, sur /bench custom reload et avec le bouton d'actualisation de l'interface. Un fichier qui pose problème n'apparaît pas dans /bench custom list, et la console dit pourquoi :

Les paramètres ne sont pas vérifiés à ce stade : /bench custom info les affiche tels qu'ils sont écrits.

Les tests des extensions ne sont connus qu'une fois leur plugin démarré, c'est-à-dire après VoxelBench. Un profil qui en utilise un est donc rejeté au démarrage du serveur : lancez /bench custom reload une fois le serveur démarré.

Un profil de benchmark dont l'étape hopper demande plus de lignes que benchmark-tests.hopper.limits.max reçoit aussi un avertissement dans la console au chargement (sauf le profil fourni hopper-heavy.yml) : avant VoxelBench 2.0.0, un tel profil exécutait sans le dire au plus ce nombre de lignes (10 par défaut), ses anciens résultats ne se comparent donc pas aux nouveaux.

Au lancement d'un run

Toutes les étapes sont préparées avant le premier test :

• Un nombre hors de sa plage autorisée y est ramené, avec un avertissement dans le chat et dans la console, par exemple mobCount=9000 clamped to 5000 (allowed range: 10..5000). Le run continue.
• Une valeur qui n'est pas un nombre est remplacée par le défaut, avec un avertissement.
• Un nom de paramètre que le test ne connaît pas est ignoré, sans avertissement : le test tourne avec sa valeur par défaut.
• Si un test n'est plus disponible (une extension retirée après le chargement du profil), le run ne démarre pas, et un message nomme le test.

Partager un profil

Un profil tient en un seul fichier, autonome. Pour le partager, envoyez le fichier : l'autre opérateur le dépose dans plugins/VoxelBench/custom_benchmarks/ et lance /bench custom reload. Sur son serveur, le nom du fichier devient le nom du profil.

Empreinte du profil

Quand VoxelBench charge un profil, il calcule une empreinte SHA-256 de sa recette. /bench custom info en affiche les 12 premiers caractères, et un rapport envoyé à voxelbench.com la porte en entier : deux runs de même empreinte ont suivi la même recette.

Pour un profil de benchmark, l'empreinte couvre :

• le type, name, description, author, version, tags et submit ;
• toutes les clés placées sous options: ;
• les étapes, dans l'ordre : chaque test, avec ses paramètres exactement tels qu'écrits.

Elle ne dépend pas du nom du fichier (sauf en l'absence de name:, puisque le nom du fichier devient alors le nom affiché), des commentaires, des lignes vides, de l'ordre des clés sous params: ou options:, de l'ordre des tags, ni de la façon d'écrire l'identifiant du test (chunk-loading et chunkLoading donnent la même empreinte). Un paramètre omis et le même paramètre écrit avec sa valeur par défaut donnent deux empreintes différentes, tout comme une valeur hors plage et la borne à laquelle elle est ramenée.

Pour un profil de stress limit, l'empreinte couvre les mêmes métadonnées, les types de stress dans l'ordre avec leurs bornes, et chaque réglage stress tel qu'il s'applique au run : un réglage omis et le même réglage écrit avec sa valeur par défaut donnent la même empreinte.

Toute autre modification, même de la description ou de submit, change l'empreinte, et fait donc un autre profil sur voxelbench.com. L'empreinte décrit la recette, pas le serveur : les résultats dépendent toujours de la machine et des réglages de config.yml cités dans Réglages lus dans config.yml.

Sur voxelbench.com

Avec submit: false, la valeur par défaut, rien n'est envoyé : le run reste seulement dans vos rapports locaux, où le rapport d'un profil de benchmark est marqué comme non envoyé.

Avec submit: true, un profil de benchmark envoie son rapport à la fin du run, et le chat en affiche le lien. Sur voxelbench.com, ce rapport :

• appartient au compte auquel votre serveur est lié, et il est d'abord privé. Vous pouvez le rendre non répertorié (visible par qui a le lien) ou de nouveau privé, mais jamais public ;
• n'a ni VoxelScore ni rang, et n'apparaît dans aucun classement ;
• affiche une carte Profil personnalisé : nom affiché, auteur, version, description, tags, les 12 premiers caractères de l'empreinte, et le nombre de runs envoyés à voxelbench.com avec la même empreinte.

La carte omet un champ trop long : nom de fichier au-delà de 64 caractères, nom affiché ou auteur au-delà de 255, description au-delà de 2 000, tag au-delà de 32. Seuls les 20 premiers tags sont gardés. Le run lui-même est bien enregistré. Pour les rapports des tests ajoutés par des extensions, voir Créer une extension.

Un profil de stress limit avec submit: true envoie lui aussi son rapport à la fin du run. voxelbench.com le traite comme celui d'un profil de benchmark : il appartient au compte lié, il est d'abord privé et peut devenir non répertorié, jamais public, et il n'a ni score ni rang et n'apparaît dans aucun classement, puisque ses seuils de rupture et sa montée sont ceux de l'auteur du profil.

Si votre offre voxelbench.com comprend l'auto-bench, une tâche d'auto-bench peut lancer un profil de benchmark de votre serveur par son nom. Ce nom ne doit alors contenir que des lettres, des chiffres, - et _, sur 64 caractères au plus. Un tel run est toujours envoyé, quelle que soit la valeur de submit. Les profils de stress limit ne peuvent pas être lancés de cette façon.

Pièges courants

• Un nom de paramètre mal orthographié est ignoré sans avertissement : le test tourne avec sa valeur par défaut. Comparez les noms qu'affiche /bench custom info au tableau des paramètres.
• Une étape écrite - disk au lieu de - id: disk est ignorée. Chaque étape doit être une table avec un id:.
• kind: stress-limit n'est pas kind: stresslimit : toute autre valeur donne un profil de benchmark, ignoré ensuite faute de tests:.
• Un profil qui utilise un test d'extension disparaît après un redémarrage : lancez /bench custom reload une fois le serveur démarré.
• dispersedZones: 2 ou 4 ne veut pas dire 2 ou 4 zones pour chunkLoading, mobSpawn, hopper et explosion : toute valeur supérieure à 1 désigne les 8 zones du run.
• options.auto-temp-world: true ne peut pas créer de monde temporaire quand benchmark.auto-temp-world vaut false dans config.yml : le run utilise le monde principal.
• mobCount et tntCount s'arrêtent aux limites de config.yml (1 000 mobs et 200 TNT par défaut), sans avertissement.
• Un nouveau fichier de profil n'a aucun effet avant /bench custom reload ou un redémarrage du serveur.
• Un profil de stress limit absent de l'autocomplétion ou de l'interface n'est pas cassé : le lancer exige voxelbench.stresslimit, et il n'est proposé qu'aux joueurs qui l'ont. /bench custom list l'affiche.