Référence des commandes

Tapez /bench ou /bench help pour afficher la liste des commandes en jeu. Une sous-commande inconnue affiche une erreur suivie de cette même liste.

Joueur ou console ? /bench start, /bench stresslimit, /bench tier, /bench custom run, /bench gui et les tests marqués « Non » dans les tableaux des tests doivent être lancés par un joueur connecté au serveur : ils dépendent de l'activation des chunks, du tick des entités et de la sauvegarde/restauration de l'état du joueur. /bench zones tp, /bench reports et /bench reports gui, /bench lang auto, /bench monitor gui et /bench monitor bars <métrique> exigent aussi un joueur. Les autres commandes fonctionnent aussi depuis la console.

Toute commande exige voxelbench.use. La colonne Permission indique ce qu'une commande demande en plus (voxelbench.use = rien de plus) ; voir Permissions pour le détail.

Commandes générales

Commandes de benchmark

/bench zones montre les zones du dernier run qui en a disposé depuis le démarrage du serveur (un run de benchmark, de stress limit, de palier, de profil personnalisé ou d'auto-bench ; /bench test n'en enregistre aucune) et nomme le monde qu'a utilisé ce run. Un monde temporaire est supprimé à la fin de son run, et ses zones avec lui : la commande indique alors que ce monde n'existe plus, sans renvoyer vers un autre monde. Sans run enregistré, elle montre la zone par défaut du monde épinglé, s'il y en a un. clean retire toutes les entités, hors joueurs, tableaux et cadres, à moins de 200 blocs de chaque zone, et seulement dans un monde voxelbench_* : dans tout autre monde, le monde principal ou un monde épinglé d'un autre nom, il ne retire rien et dit pourquoi. Chaque test retire déjà ce qu'il a fait apparaître, y compris quand /bench stop l'interrompt ; le balayage supplémentaire des emplacements de test fixes qui suit /bench stop n'a lieu, lui aussi, que dans un monde voxelbench_*.

VoxelBench 2.0.2 et versions antérieures : sur Paper et Spigot, /bench start, /bench stresslimit, /bench tier et /bench custom run retiraient, au début du run, villageois, animaux (apprivoisés et nommés compris), golems, objets au sol, wagonnets et bateaux de tous les mondes chargés ; /bench stop retirait villageois, chats, golems et objets au sol autour d'emplacements fixes du monde du test, quel qu'il soit ; et, sans monde épinglé, /bench zones clean balayait une zone du monde principal. Mettez à jour avant de les lancer sur un serveur dont les mondes comptent. Voir Garde-fous.

Benchmark complet

/bench start

Exécute la suite de tests en trois phases : matériel, puis gameplay, puis CPU (voir Benchmarks). Les résultats sont soumis à voxelbench.com.

Les arguments peuvent être donnés dans n'importe quel ordre :

Exemples :

/bench start 5
/bench start warmup 3
/bench start force warmup 3

Quand confirmation.require-confirmation vaut true (valeur par défaut), VoxelBench effectue des vérifications préalables avant de démarrer. Si rien n'est détecté, le benchmark démarre aussitôt. Sinon, un écran d'inventaire liste les constats et vous cliquez pour lancer ou annuler. Les constats critiques, comme viser un monde qui n'est pas un monde voxelbench_*, ne peuvent être outrepassés que par un joueur disposant de voxelbench.start.force.

Mode multi-run

Avec plus d'un run (ou avec warmup), VoxelBench précharge les chunks autour des zones de test, réutilise les mêmes zones et le même monde pour chaque run, et attend 10 secondes avant le suivant. Dans un monde voxelbench_* (le monde temporaire, ou un monde créé avec /bench world create), il réinitialise aussi les régions de test entre deux runs, pour que chaque run reparte d'un terrain fraîchement généré ; dans tout autre monde, il ne force ni ne supprime rien, le signale, et les runs réutilisent les chunks déjà générés. Chaque run produit son propre rapport. Voir Mondes de benchmark.

VoxelBench 2.0.2 et versions antérieures : sans monde épinglé, une session multi-run réinitialisait entre deux runs des régions du monde principal du serveur. Mettez à jour avant d'en lancer une, ou épinglez un monde voxelbench_*.

Mondes de benchmark

Commandes de tests individuels

Les identifiants de test ne tiennent pas compte de la casse, et les - ou _ sont ignorés : chunkLoading, chunkloading et chunk_loading désignent le même test. Les valeurs positionnelles (plus bas) ne fonctionnent qu'avec les noms du tableau des valeurs positionnelles, quelle que soit la casse ; avec une autre graphie, comme chunk_loading, le test prend des paires clé=valeur.

Tests disponibles

VoxelBench embarque 26 tests intégrés. La colonne « Console » indique si le test peut être lancé depuis la console. Quand un test réservé aux joueurs est lancé depuis la console, le message d'erreur cite quelques exemples et renvoie vers /bench test list ; les tableaux ci-dessous donnent la liste complète.

Tous les tests de gameplay sauf worldSave écrivent dans le monde : /bench test les lance donc dans le monde épinglé ou dans un monde temporaire, jamais dans celui où vous vous trouvez, et les refuse quand ni l'un ni l'autre n'est possible (toujours le cas sur Folia sans monde épinglé). Voir Benchmarks.

Matériel

CPU single-core

Gameplay

Paramètres des tests

Sans paramètre, la plupart des tests utilisent leurs valeurs par défaut. Deux syntaxes coexistent, selon le nom tapé.

Valeurs positionnelles. Ces noms prennent des valeurs brutes dans un ordre fixe :

Valeurs nommées. Tous les autres identifiants (lightingUpdate, entityCollision, tickingTileEntity, villagerTrading, projectileStorm, entityCramming, playerWorldLoad, singleCoreBenchmark et les tests ajoutés par des extensions) prennent des paires clé=valeur :

/bench test projectileStorm projectilesPerWave=250 durationSeconds=20
/bench test singleCoreBenchmark durationSeconds=15 kernel=float

Les noms de paramètres sont ceux des profils personnalisés ; le fichier fourni custom_benchmarks/showcase.yml les documente pour chaque test. Une valeur clé=valeur hors limites est ramenée dans la plage autorisée, avec un avertissement. Une valeur positionnelle hors limites est le plus souvent refusée, avec une erreur qui donne la plage autorisée.

Commandes Stress Limit

Voir Stress Limit pour les types de stress et les options de /bench tier.

Commandes des profils personnalisés

/bench custom run accepte aussi warmup et un nombre de runs, mais les profils n'exécutent pour l'instant qu'une seule itération. Sans voxelbench.stresslimit, les profils de stress limit n'apparaissent ni dans l'autocomplétion de run, ni dans l'écran des profils de l'interface, ni dans la liste des profils disponibles affichée après un nom inconnu ; list et info les montrent toujours. Voir Benchmarks - Profils personnalisés.

Commandes de monitoring

Voir Monitoring pour les détails.

Commandes de profilage (expérimental)

Échantillonnent les threads de tick avec Java Flight Recorder et montrent quels plugins et quelles méthodes y tournent. Rien ne quitte le serveur sauf si vous envoyez vous-même un profil avec /bench profile upload, ou le partagez par lien public avec /bench profile share. Les captures sont refusées pendant un benchmark, un stress limit, un palier, un run d'auto-bench ou un /bench test dont le résultat est envoyé à voxelbench.com, et dans les 30 s qui suivent.

Voir Profilage pour lire les résultats et comprendre les vidages automatiques sur lag.

Commandes d'inspection mémoire (expérimental)

Voir ce qui remplit la mémoire du serveur, par plugin, écrire un vidage complet du tas — l'équivalent de heapsummary et heapdump de spark — et l'analyser dans un processus séparé pour savoir quel plugin retient la mémoire. Un résumé ou une analyse ne quitte le serveur que si vous l'envoyez avec /bench memory upload ou le partagez par lien public avec /bench memory share ; un vidage du tas ne le quitte jamais, par aucune commande. Refusé pendant un benchmark, un stress-limit, un palier, un run d'auto-bench ou un /bench test dont le résultat est envoyé à voxelbench.com, et dans les 30 s qui suivent.

<id|#|last> désigne un résumé ou une analyse : son identifiant, un préfixe unique, last (le plus récent des deux) ou #N (rang parmi les résumés et les analyses ensemble, du plus récent au plus ancien). Voir Inspection mémoire pour lire un résumé ou une analyse, savoir ce que coûte un vidage et comment l'ouvrir, et ce qui part quand vous envoyez ou partagez un rapport.

Formulaires des commandes tapées sans option

Tapées seules par un joueur, /bench profile, /bench memory summary, /bench memory dump et /bench memory analyze ouvrent un formulaire avec leurs options au lieu de partir avec les valeurs par défaut : un dialogue natif sur Paper 1.21.6 et suivants, un écran d'inventaire ailleurs (clic : valeur suivante, Maj+clic : précédente). Il propose la durée et l'intervalle d'échantillonnage, objets vivants ou tous, gzip, le mode d'analyse, le vidage à analyser, et s'il faut garder, partager ou envoyer le résultat — seulement ce que vos permissions et config.yml permettent.

Le formulaire ne fait que construire la commande et la lancer comme si vous l'aviez tapée : ses permissions et ses refus s'appliquent, et un vidage montre toujours son aperçu et attend sa confirmation. La console, et toute commande tapée avec ses options, fonctionnent comme avant (depuis la console, /bench profile seul capture toujours 30 s).

Chaque formulaire rouvre sur vos derniers choix (par joueur, gardés d'un redémarrage à l'autre dans plugins/VoxelBench/form-choices.json) : durée, intervalle, objets vivants ou tous, gzip, mode d'analyse, plugin visé. Un choix qui n'est plus proposé (permission retirée, réglage changé) revient à sa valeur par défaut. Trois choix repartent toujours de leur défaut et ne sont jamais repris : garder, partager ou envoyer le résultat, forcer un vidage malgré le chien de garde, et le vidage à analyser (le plus récent).

Confirmer un aperçu

Un vidage du tas, et upload/share … preview pour les profils et les rapports mémoire, montrent d'abord un aperçu et attendent confirm. Trois façons de le donner, qui lancent toutes cette même commande … confirm, avec les mêmes contrôles : même joueur ou même console, dans les 60 s, mêmes options, fichier inchangé, permissions.

• /bench confirm (ou /b confirm) confirme le dernier aperçu de celui qui la tape — console comprise : /bench memory dump live gzip analyze full share est suivi de /bench confirm au lieu de toute la ligne ;
• un clic sur la ligne de confirmation dans le chat ;
• pour un joueur, Oui dans la fenêtre qui s'ouvre avec l'aperçu : un dialogue natif sur Paper 1.21.6 et suivants, un écran d'inventaire ailleurs. Non (ou Échap) ne fait rien. confirmation.popup: false dans config.yml retire la fenêtre.

Commandes de rapports

Commandes de vérification du serveur

Commandes de liaison de compte

Commandes internes

/bench autobot et /vbautobot servent uniquement à l'agent d'auto-bench de VoxelBench. Elles ne font rien tant que le code à usage unique qu'elles transportent n'est pas validé par le backend. Vous n'avez jamais à les taper.