Configuration

/bench reload recharge le fichier. La plupart des réglages sont lus au moment où ils servent : ils s'appliquent donc au prochain benchmark ou test. Quelques-uns ne sont lus qu'au démarrage et nécessitent un redémarrage du serveur : les réglages de langue, le cooldown du rate limit, update-check, la détection de l'hébergement et les intégrations. Le monitoring distant est appliqué par /bench reload : il démarre, s'arrête ou redémarre avec les nouveaux réglages. Les réglages de monitoring ont leur propre /bench monitor reload (redémarrez ensuite le serveur web), et les profils personnalisés se relisent avec /bench custom reload.

Quand VoxelBench est mis à jour, les clés manquantes sont ajoutées automatiquement à votre config.yml. Voir Mettre à jour un config.yml existant.

Langue

language:
  default: en_US    # Langue par défaut, utilisée quand la langue du joueur n'est pas disponible
  force: false      # Imposer la langue par défaut à tous les joueurs

• Quand force: false (par défaut), VoxelBench détecte automatiquement la langue du client Minecraft de chaque joueur. Un joueur peut la remplacer avec /bench lang <code> et revenir à la détection avec /bench lang auto.
• Quand force: true, tous les joueurs voient les messages dans la langue default
• Langues fournies : en_US (anglais), fr_FR (français)

Les fichiers de langue sont extraits dans plugins/VoxelBench/lang/. Vous pouvez les modifier ; les clés manquantes sont complétées depuis le plugin au démarrage. VoxelBench charge aussi un fichier de traduction déposé dans ce dossier pour l'un de ces codes : de_DE, es_ES, it_IT, pt_BR, ru_RU, zh_CN, ja_JP, ko_KR, pl_PL, nl_NL, tr_TR.

Le tableau de bord web a ses propres traductions (anglais et français), choisies d'après la langue du navigateur ou le sélecteur de la page.

Mode de fonctionnement

mode: anonymous    # anonymous ou authenticated

Utilisez /bench link pour passer en mode authentifié. Voir Liaison de compte.

server-name: ""    # Nom proposé pour ce serveur lors de la liaison avec /bench link

Si server-name est vide, aucun nom n'est envoyé pendant la liaison.

Notifications

notifications:
  sounds:
    enabled: true    # Jouer des sons à la fin des tests/benchmarks

Vérification des mises à jour

update-check: true

Environ 5 secondes après le démarrage, VoxelBench demande à voxelbench.com si une version plus récente existe. Si c'est le cas, elle est annoncée dans la console, et les opérateurs ainsi que les joueurs disposant de voxelbench.admin en sont informés en jeu (aussi lorsqu'ils se connectent). Mettez false pour désactiver cette vérification.

Anonymisation

Contrôle les données incluses lors de l'envoi des rapports à voxelbench.com.

anonymous:
  anonymization-level: PARTIAL    # NONE, PARTIAL ou FULL

Tous les niveaux envoient toujours : nom du CPU, quantité de RAM, version Java, nom de l'OS, et toutes les métriques de benchmark.

Voir Confidentialité et sécurité pour plus de détails.

Rate Limiting

rate-limiting:
  local-cooldown-minutes: 30    # Minutes entre les benchmarks

Empêche de lancer des benchmarks trop fréquemment. Les joueurs avec la permission voxelbench.start.force peuvent ignorer ce cooldown.

Mode de benchmark

benchmark-mode: standard    # standard ou custom

Le mode ne change que ce qu'exécute /bench start (voir Benchmarks). Les profils personnalisés et /bench test prennent leurs paramètres dans le profil ou sur la ligne de commande.

Paramètres de test personnalisés

La section tests: et les quantités de benchmark-tests: sont utilisées par /bench start quand benchmark-mode: custom :

tests:
  single-core-benchmark:
    duration: 10                # Durée de mesure en secondes
  multi-core:
    threads: 100
    iterations: 100000
    limits:                     # Bornes pour /bench test multiCore
      threads-min: 1
      threads-max: 200
      iterations-min: 1000
      iterations-max: 1000000
  disk:
    threads: 4
    queue-depth: 8
    file-size-mb: 512
    random-4k-operations: 200   # En milliers (200 = 200 000 opérations)
    passes: 3
    limits:                     # Bornes pour /bench test disk
      size-min-mb: 64
      size-max-mb: 4096
      threads-min: 1
      threads-max: 32
      queue-depth-min: 1
      queue-depth-max: 64
      passes-min: 1
      passes-max: 20
  memory:
    size-mb: 512
    iterations: 75000
    runs: 3
    limits:                     # Bornes pour /bench test memory
      size-min-mb: 16
      size-max-mb: 1024
      passes-min: 1
      passes-max: 10
  block-physics:
    count: 24000                # Blocs qui tombent
    interval-ticks: 1           # Ticks entre deux vagues d'apparition

benchmark-tests:
  chunk-loading:
    chunks-to-load: 200
    limits: { min: 10, max: 5000 }
    adaptive:                   # Régulation du chargement (/bench test, mode custom, profils personnalisés)
      window-max: 200
      target-mspt-ms: 75.0
      soft-cap-mspt-ms: 100.0
      critical-mspt-ms: 250.0
  mob-spawn:
    mob-count: 300
    duration-seconds: 30
    limits: { min: 10, max: 1000 }
  hopper:
    hopper-chain-length: 50
    parallel-lines: 1
    limits: { min: 1, max: 10 }
  explosion:
    tnt-count: 30
    raise-host-tnt-quota: true
    limits: { min: 1, max: 200 }
  dispersed-zones:
    default: 8
    limits:
      min: 1
      max: 10

Quelques-uns de ces réglages ne se limitent pas au mode custom :

• chunk-loading.adaptive règle la vitesse à laquelle un run de chargement de chunks pousse la génération : le budget par tick augmente tant que le MSPT reste sous target-mspt-ms, recule au-dessus de soft-cap-mspt-ms et tombe à un chunk par tick au-dessus de critical-mspt-ms. Gardez les valeurs par défaut sauf raison précise.
• explosion.raise-host-tnt-quota: true relève en mémoire le max-tnt-per-tick de Spigot pendant un test d'explosions, puis le restaure (spigot.yml n'est jamais modifié). Avec false, la limite de l'hôte n'est pas touchée et un run dont toutes les charges n'ont pas pu tick est signalé comme une mesure partielle.
• hopper.hopper-chain-length et mob-spawn.duration-seconds s'appliquent aux tests de hoppers et d'apparition de mobs hors benchmark standard (le stress limit fixe sa propre longueur de chaîne).
• Les limits de chunk-loading, mob-spawn et explosion plafonnent la quantité reçue par ces tests dans /bench test, en benchmark-mode: custom et dans les profils personnalisés. Elles sont relues à chaque run : un /bench reload suffit donc à appliquer une nouvelle borne.
• Les limits de hopper ne bornent que /bench test hopper <lignes>. Un profil personnalisé exécute le nombre de lignes qu'il demande, jusqu'à 500 par zone, quoi que disent ces limites (voir Profils personnalisés).
• mob-pathfinding, redstone et block-physics n'ont pas de bloc limits : /bench test valide leurs arguments contre des plages fixes, rappelées dans le message d'erreur quand une valeur sort de la plage.
• Le /bench start standard ignore tout ce qui précède (limits, adaptive, hopper-chain-length, dispersed-zones.limits) : il exécute toujours la même charge fixe — 10 lignes de hoppers × 50, 150 TNT, 2000 chunks par zone avec la régulation par défaut, 8 zones — pour qu'un score standard mesure la même chose sur tous les serveurs. Seul explosion.raise-host-tnt-quota s'applique encore, parce que c'est une autorisation de toucher aux réglages de l'hôte, pas un réglage de charge.
• Tout run de chargement de chunks reste sous un plafond mémoire qu'aucun réglage ne modifie : 30 % du tas maximal, à environ 50 Ko par chunk, partagés entre les zones que le test parcourt, sans jamais descendre sous 200 chunks par zone. Avec 8 zones, une zone reçoit au plus 0,75 chunk par Mo de tas maximal : les 2000 chunks par zone du standard demandent donc un tas maximal d'environ 2 670 Mo, et sur un tas plus petit le benchmark standard en charge moins.

Zones dispersées

dispersed-zones.default est le nombre de zones de test, très éloignées les unes des autres dans le monde de benchmark, qu'utilisent les tests multi-zones en benchmark-mode: custom. La valeur est maintenue dans limits et toujours entre 1 et 10. Le benchmark standard et les profils personnalisés utilisent toujours 8 zones, quelle que soit cette valeur, pour que leurs résultats restent comparables.

Runs de benchmark

Tous les réglages benchmark: se trouvent dans un seul bloc :

benchmark:
  target-world: ""           # Monde épinglé, défini avec /bench world set
  auto-temp-world: true      # Créer un monde plat temporaire quand aucun monde n'est épinglé

  post-cleanup-gc: true      # GC complet après le nettoyage de chaque test

  memory-budget:             # Contrôlé avant chaque test
    enabled: true
    warn-pct: 75.0
    fail-pct: 85.0

  memory-watchdog:           # Surveille le heap pendant chaque test
    enabled: true
    critical-pct: 92.0
    hold-seconds: 3

• target-world : le monde utilisé par tous les benchmarks, tests et stress. Définissez-le avec /bench world set <nom> et retirez-le avec /bench world unset. Si le monde épinglé n'est pas chargé, VoxelBench prévient et ignore l'épinglage.
• auto-temp-world : quand aucun monde n'est épinglé, /bench start, /bench stresslimit, /bench tier et les profils personnalisés créent un monde plat temporaire nommé voxelbench_temp_<horodatage>, s'y exécutent puis le suppriment à la fin (le monde est aussi importé dans Multiverse-Core s'il est installé). Un profil de benchmark personnalisé peut seulement le désactiver pour ses propres runs, avec options.auto-temp-world: false : true dans un profil ne crée aucun monde temporaire quand ce réglage vaut false (voir Profils personnalisés). Avec false, ces runs utilisent le monde principal du serveur, et les vérifications préalables de /bench start signalent un constat critique « Aucun monde cible configuré ». /bench test l'applique autrement. Un test qui écrit dans le monde (tous les tests de gameplay sauf worldSave) ne tourne jamais dans le monde où vous vous trouvez : il utilise le monde épinglé, sinon un monde temporaire, et avec auto-temp-world: false il est refusé. Sur Folia, qui ne sait pas créer de monde en cours de route, un tel test exige un monde épinglé. Les tests matériels et CPU et worldSave utilisent le monde épinglé, ou celui où vous vous trouvez (voir Benchmarks).
• post-cleanup-gc : force un garbage collection complet après le nettoyage de chaque test, pour que la mémoire laissée par un test ne pèse pas sur le suivant.
• memory-budget : avant chaque test, VoxelBench estime l'occupation du heap que le test va atteindre. À partir de warn-pct pour cent du heap maximum, il lance d'abord un garbage collection ; si l'estimation reste supérieure ou égale à fail-pct pour cent ensuite, le test est ignoré et signalé comme tel plutôt que de risquer un crash par manque de mémoire.
• memory-watchdog : pendant un test, si l'occupation du heap reste supérieure ou égale à critical-pct pour cent pendant hold-seconds secondes consécutives, le test est interrompu et signalé comme ignoré.

Gardez toutes ces clés sous un seul bloc benchmark: : si un fichier YAML déclare deux fois la même clé de premier niveau, seul le dernier bloc est conservé.

Confirmation

confirmation:
  require-confirmation: true    # Effectuer les vérifications préalables avant /bench start
  popup: true                   # Fenêtre Oui/Non après un aperçu qui attend « confirm »

/bench start n'a pas de commande de confirmation. Quand require-confirmation vaut true (défaut), /bench start effectue d'abord les vérifications préalables :

• Si rien n'est détecté, le benchmark démarre aussitôt.
• Sinon, un écran d'inventaire liste les constats (monde non plat, autres joueurs connectés, serveur déjà chargé, hébergement gratuit, plugins susceptibles d'interférer...). Cliquez sur Start benchmark pour lancer le benchmark ou sur Cancel pour abandonner.
• Quand un constat est critique (par exemple, le monde cible n'est pas un monde voxelbench_*), le bouton de démarrage normal est désactivé. Seul un joueur disposant de voxelbench.start.force obtient un bouton Force start.

Avec false, /bench start saute les vérifications préalables et démarre immédiatement.

Cette option ne concerne que /bench start. /bench stresslimit demande toujours de retaper la commande dans les 10 secondes, tandis que /bench tier et /bench custom run démarrent sans confirmation.

popup concerne les commandes qui montrent un aperçu et attendent confirm : un vidage du tas, et upload/share … preview pour les profils et les rapports mémoire. Avec true (défaut), un joueur reçoit aussi une fenêtre Oui/Non avec l'aperçu — un dialogue natif sur Paper 1.21.6 et suivants, un écran d'inventaire ailleurs — dont le Oui lance la commande … confirm elle-même, avec tous ses contrôles. Avec false, restent la ligne cliquable du chat et /bench confirm. Relu à chaque aperçu : /bench reload suffit. Voir Confirmer un aperçu.

Détection de l'hébergement

hosting-detection:
  enabled: true     # Détecter l'environnement d'hébergement au démarrage
  silent: false

Au démarrage, VoxelBench recherche les signes d'un hébergement gratuit ou mutualisé (par exemple Aternos, Minehut, ou un panneau d'hébergement avec peu de mémoire) et classe le serveur, de DEDICATED_OR_VPS à CONFIRMED_FREE. Le résultat est écrit dans les logs, et lorsqu'un hébergement gratuit est probable :

• un avertissement détaillant les raisons est écrit dans les logs de démarrage
• les vérifications préalables de /bench start affichent un constat « Hébergement gratuit détecté », qui renvoie vers le profil allégé free-host
• le bloc hostingEnvironment du rapport contient le niveau détecté, l'hébergeur et les signaux, pour que voxelbench.com puisse distinguer ces runs

silent: true enregistre l'avertissement comme non affiché (warningEmitted: false) dans les rapports ; il ne masque ni l'avertissement des logs de démarrage ni le constat des vérifications préalables. Avec enabled: false, aucune détection n'a lieu. Les changements nécessitent un redémarrage.

Stress Limit

stress-limit:
  warm-start:
    enabled: true                # false = toujours monter depuis la charge de départ
    factor: 0.70                 # démarrer à 70 % de la dernière valeur stable
    max-refine-down-steps: 6     # étapes de dichotomie quand la sonde à chaud rompt
    max-age-days: 30             # ignorer les valeurs mémorisées plus anciennes

Après chaque run Stress Limit complet, VoxelBench mémorise la dernière charge stable de chaque type de stress dans plugins/VoxelBench/stress-warmstart.yml. Avec le démarrage à chaud, le run suivant démarre à factor fois cette valeur au lieu de monter depuis la charge de départ. Si ce premier palier rompt, il cherche vers le bas pendant au plus max-refine-down-steps étapes, puis repart de la charge de départ si rien ne tient. /bench tier ... cold ignore le démarrage à chaud le temps d'un run. Voir Stress Limit.

Les autres réglages du Stress Limit (seuils, montée, durée des paliers) ne sont pas dans config.yml : ils sont fixes pour le run officiel et se modifient dans un profil de stress personnalisé.

Journalisation

logging:
  test-verbosity: NORMAL    # MINIMAL, NORMAL, VERBOSE, DEBUG
  log-test-results: true    # Afficher le résumé de chaque test
  log-benchmark-progress: true    # Afficher quel test est en cours

Ces réglages sont appliqués par /bench reload.

benchmark-diagnostics: false

Aide au dépannage des benchmarks : avec true, VoxelBench compte les entités, items au sol, mobs et chunks chargés de chaque monde avant et après chaque test, et prévient quand le nettoyage d'un test a laissé quelque chose derrière lui. Les comptages eux-mêmes sont écrits dans les logs en verbosité VERBOSE.

Monitoring

Voir Monitoring pour le fonctionnement de chaque fonctionnalité. Appliquez les changements avec /bench monitor reload, puis redémarrez le serveur web (/bench monitor web stop, puis start).

monitor:
  web-port: 8080                 # Port HTTP du tableau de bord et de /api/metrics
  bind-address: "127.0.0.1"      # Cette machine seulement ; toute autre adresse exige un mot de passe

  https:
    enabled: false               # Servir en HTTPS sur https.port au lieu de web-port
    port: 8443
    keystore-path: "certificates/keystore.jks"   # Relatif à plugins/VoxelBench/
    keystore-password: ""        # Rempli par /bench monitor https generate
    key-alias: "voxelbench"

  auto-start:                    # Démarrer les services au lancement du serveur
    web-server: false
    push-service: false
    boss-bars: false             # Boss bars TPS + MSPT (voir Monitoring pour savoir qui les voit)

  dashboard:
    enabled: true                # false = /api/metrics seule, sans page HTML

  auth:
    enabled: false
    username: "admin"
    password-hash: ""            # Défini depuis la console : /bench monitor auth password <mot de passe> (12 caractères min.)
    password-salt: ""
    session-timeout: 60          # Minutes
    api-key: ""                  # Défini avec /bench monitor auth key pull

  behind-proxy: false            # true uniquement derrière un reverse proxy de confiance (lit X-Forwarded-For)

  whitelist:
    enabled: false
    mode: "all"                  # all, dashboard ou api
    allowed-ips:
      - "127.0.0.1"
      - "::1"
    denied-message: "Access denied: Your IP is not whitelisted"

  push:
    enabled: false               # Affiché dans l'interface ; le push démarre avec /bench monitor push start ou auto-start
    url: ""                      # Destination des requêtes POST
    api-key: ""                  # Envoyée en « Authorization: Bearer » ; /bench monitor auth key push
    interval-seconds: 1
    allow-insecure: false        # Accepter les certificats TLS non vérifiés

Ne mettez jamais behind-proxy: true sur un tableau de bord exposé directement sur Internet : n'importe quel client pourrait alors falsifier son adresse IP et contourner la whitelist.

Rapports

Voir Rapports pour les détails.

reports:
  enabled: true          # false désactive les rapports locaux et /bench reports
  folder: "reports"      # Relatif à plugins/VoxelBench/

  backend:
    unit-tests: false    # Envoyer les résultats de /bench test et /bench tier (nécessite /bench link)

  retention:             # -1 = illimité
    max-age-days: 90     # Supprimer les rapports de plus de 90 jours
    max-per-type: 100    # Maximum par type
    max-total: 500       # Maximum total
    cleanup-on-startup: true

  storage:               # Types de rapports sauvegardés localement
    unit-tests: true     # /bench test
    benchmarks: true     # /bench start
    stresslimit: true    # /bench stresslimit, /bench tier, profils de stress

Les benchmarks complets et les runs Stress Limit sont soumis à voxelbench.com quels que soient ces réglages (un profil personnalisé seulement avec submit: true dans le profil) ; reports.backend.unit-tests ne concerne que les résultats des tests individuels. Ces réglages ne décident que de ce qui est écrit sur le disque : un run dont le type est désactivé ici ne laisse aucun rapport local.

Monitoring distant

Le monitoring distant envoie des relevés de métriques périodiques et les événements détectés au tableau de bord de votre serveur sur voxelbench.com. Il nécessite un serveur lié.

Le plus simple pour l'activer est /bench monitor remote on : la commande met enabled: true, démarre le service et vérifie aussitôt la connexion, en indiquant en jeu ce qu'il reste à faire. Modifier le fichier fonctionne aussi : mettez enabled: true puis lancez /bench reload. /bench monitor remote status indique où il en est (liaison, service, dernier contact, dernier envoi).

Le monitoring doit aussi être activé pour le serveur sur voxelbench.com (page Monitoring de votre tableau de bord), et votre offre doit l'inclure. L'ordre n'a pas d'importance : tant que le site refuse les données, le plugin se met en pause et revérifie tout seul (chaque minute, ou toutes les 10 minutes quand l'offre n'inclut pas le monitoring), puis commence à envoyer dès que le site accepte. Il ne se désactive jamais lui-même dans config.yml. Si le site ne reconnaît plus la liaison, le service s'arrête jusqu'au prochain /bench link.

remote-monitoring:
  enabled: false
  collect-interval: 60    # Secondes entre deux relevés (30 - 600)
  send-interval: 60       # Secondes entre deux envois des relevés en attente (60 - 3600)
  buffer-size: 120        # Relevés gardés en mémoire avant d'écarter les plus anciens (10 - 1000)
  folia-regions:
    max-detailed: 64      # Folia seulement : régions détaillées une à une par relevé, les pires d'abord (0 - 256)

Sous Folia, chaque relevé mesure toutes les régions et en détaille jusqu'à folia-regions.max-detailed, les pires d'abord, avec leurs coordonnées, leur TPS et leurs durées de tick (environ 200 octets chacune) ; les autres sont seulement comptées, et les valeurs pires et moyennes les couvrent toutes. 0 n'envoie que les valeurs pires et moyennes. Paper et Spigot l'ignorent. Voir Monitoring.

Les deux intervalles sont en temps réel : un serveur qui rame garde son rythme. TPS, MSPT, mémoire, CPU et GC sont lus hors du thread principal ; joueurs, entités, chunks et mondes sont lus sur le thread principal au même rythme, et laissés de côté dans un relevé quand cette lecture est trop ancienne. Un retard s'envoie en plusieurs lots de 60 relevés, et les relevés de plus de deux heures environ sont écartés, puisque voxelbench.com les refuse. À l'arrêt du serveur, les derniers relevés partent avant l'extinction. La mise à jour depuis la 1.9.0 ou avant ramène à 60 un send-interval resté à l'ancien défaut de 300 : voxelbench.com évalue les règles d'alerte chaque minute sur les données reçues. Toute autre valeur est conservée. Un collect-interval inférieur à 30 est ramené à 30 : en dessous, le budget de relevés de l'offre sur voxelbench.com refusait les relevés au bout de quelques heures, et chaque relevé indique déjà le pire tick de son intervalle.

Événements

La détection d'événements tourne tant que le monitoring distant tourne. Chaque événement a son propre interrupteur enabled ; cooldown-seconds est le délai minimal entre deux événements du même type.

remote-monitoring:
  events:
    enabled: true

    performance:
      tps-drop:                # TPS sous le seuil pendant au moins duration-seconds
        enabled: true
        threshold: 18.0
        duration-seconds: 10
        cooldown-seconds: 60
      tps-critical:            # TPS sous le seuil, signalé immédiatement
        enabled: true
        threshold: 10.0
        cooldown-seconds: 120
      tps-recovery:            # Envoyé quand une chute prolongée prend fin
        enabled: true
      gc-major:                # Pauses GC majeures (old-gen / heap complet) sur 5 s
        enabled: true
        threshold-ms: 200
        cooldown-seconds: 30

    memory:                    # percent = heap utilisé / heap maximum
      high:
        enabled: true
        percent: 80
        cooldown-seconds: 300
      critical:
        enabled: true
        percent: 95
        cooldown-seconds: 120

    security:
      op-changes:
        enabled: true
      config-reload:           # Envoyé lors d'un /bench reload
        enabled: true
      whitelist-changes:
        enabled: true
      check-interval: 30       # Secondes entre deux contrôles de la liste des ops et de la whitelist (5 - 3600)

    player:                    # percent = part des emplacements joueurs du serveur
      high:
        enabled: true
        percent: 80
        cooldown-seconds: 300
      full:
        enabled: true
        cooldown-seconds: 300

    litebans:                  # Nécessite LiteBans ; pris en compte au prochain redémarrage
      enabled: false           # Désactivé par défaut : les sanctions nomment des joueurs
      bans: true
      mutes: true
      kicks: true
      include-reason: false    # Envoyer aussi le motif saisi par le modérateur

• Le TPS et le GC sont relevés toutes les 5 secondes, la mémoire toutes les 15 secondes.
• tps-recovery utilise le seuil et le délai de tps-drop.
• Les événements LiteBans transmettent les bans, mutes et kicks (et leur levée) avec le joueur et le modérateur, et le motif seulement avec include-reason: true ; voir Intégrations. Une nouvelle installation les a désactivés ; un config.yml existant garde sa valeur de enabled.
• Une clé absente se comporte comme la valeur par défaut indiquée ici.

Profilage (expérimental)

Réglages de /bench profile, voir Profilage. Une valeur hors bornes est ramenée à la borne indiquée.

profiling:
  enabled: true                  # false : toute action de /bench profile est refusée
  ring:
    enabled-on-start: false      # démarrer le tampon circulaire avec le serveur (opt-in)
    period-ms: 20                # 10-100
    max-age-seconds: 300         # 60-3600
    max-size-mb: 32              # 4-512, dans le dépôt de JFR (répertoire temporaire de la JVM)
  auto-dump:
    enabled: true                # seulement quand le tampon tourne
    slow-tick-ms: 100            # 55-10000
    consecutive-slow-ticks: 40   # 1-1200
    freeze-ms: 1000              # au moins slow-tick-ms, au plus 60000
    cooldown-seconds: 300        # 30-86400
  storage:
    max-files: 20                # 1-500
    max-total-mb: 100            # 1-10240
    keep-raw-jfr: false          # garder aussi le .jfr brut à côté de chaque JSON
  upload:
    enabled: true                # false : /bench profile upload est refusé
    max-size-kb: 1024            # 64-4096, JSON non compressé
  share:
    enabled: true                # false : /bench profile share est refusé (unshare fonctionne toujours)
    max-size-kb: 1024            # 64-4096, copie nettoyée non compressée

/bench reload applique tout de suite les seuils du vidage automatique et les limites de rétention ; les réglages du tampon s'appliquent à son prochain démarrage (/bench profile ring off, puis on).

Inspection mémoire (expérimental)

Réglages de /bench memory, voir Inspection mémoire. Une valeur hors bornes est ramenée à la borne indiquée ; tout changement s'applique à la commande suivante (sans rechargement).

memory-inspection:
  enabled: true                  # false : toute action /bench memory est refusée
  summary:
    max-files: 20                # 1-500
    max-total-mb: 20             # 1-1024
  host-disk-limit-gb: 0          # 0-1048576 (0 : aucune ou inconnue)
  dump:
    enabled: true                # false : /bench memory dump est refusé
    max-files: 2                 # 1-10
    min-free-disk-mb: 1024       # 0-1048576
  analysis:
    enabled: true                # false : /bench memory analyze est refusé
    max-heap-mb: 4096            # 256-65536
    disk: true                   # false : l'analyse complète ne range jamais son graphe sur disque
    memory-margin-mb: 512        # 0-65536
    timeout-seconds: 1800        # 60-7200
    cpu-throttle:
      max-cores: 2               # 0-256 (0 : jamais freinée)
      percent: 30                # 5-100
    max-files: 20                # 1-500
    max-total-mb: 20             # 1-1024
  upload:
    enabled: true                # false : /bench memory upload est refusé
    max-size-kb: 1024            # 64-4096
  share:
    enabled: true                # false : /bench memory share est refusé (unshare marche toujours)
    max-size-kb: 1024            # 64-4096

Mettre à jour un config.yml existant

Au démarrage, VoxelBench ajoute à votre config.yml les clés introduites par une nouvelle version sans toucher à vos valeurs, puis applique les migrations ponctuelles repérées par config-version (ne modifiez pas cette clé).

• Bloc benchmark: en double. Les anciens fichiers fournis déclaraient benchmark: deux fois. YAML ne garde que le dernier bloc : tout ce qui était écrit dans le premier (typiquement target-world et auto-temp-world) était ignoré sans avertissement. Quand VoxelBench trouve une clé de premier niveau déclarée plusieurs fois, il écrit un avertissement dans les logs et réécrit le fichier avec un seul bloc. Les valeurs qui se trouvaient dans le bloc ignoré ne sont pas récupérées : redéfinissez-les (par exemple avec /bench world set).
• config-version 9. benchmark-tests.dispersed-zones.default était ignoré (chaque run utilisait 8 zones). Un default: 1 hérité d'un ancien fichier est réécrit en 8 ; toute autre valeur est conservée et désormais appliquée en mode custom.
• Clés abandonnées. Ces clés n'ont jamais été lues et ont été retirées du fichier fourni ; vous pouvez les supprimer du vôtre : tests.single-core.*, tests.network.test-servers, benchmark-tests.chunk-loading.radius, benchmark-tests.hopper.items, benchmark-tests.world-save, les blocs benchmark-tests.mob-pathfinding, benchmark-tests.redstone et benchmark-tests.block-physics en entier (quantité, durée et limits), et reports.auto-show-report.
• Clés ajoutées. update-check, server-name, benchmark-diagnostics, tests.single-core-benchmark.duration, tests.disk.random-4k-operations, tests.disk.passes, tests.block-physics.count et tests.block-physics.interval-ticks.

Intégrations

Voir Intégrations pour la référence complète de la configuration des intégrations.

integrations:
  dynmap:
    enabled: true
  spark:
    enabled: true
  discordsrv:
    enabled: true
    channel-id: ""