Comment fonctionne le scoring
VoxelBench produit un score de performance composite qui reflète la capacité de votre serveur Minecraft à gérer des charges réelles. Cette page explique la philosophie du scoring, ce qui est mesuré, et comment le score final est déterminé.
Composition du score
Le score total est construit à partir de trois catégories principales, chacune testant un aspect différent des performances serveur :
| Catégorie | Poids | Ce qu'elle mesure |
|---|---|---|
| Performance monocœur | 40% | Rapidité du CPU sur la boucle de jeu monothread |
| Score gameplay | 40% | Comportement du serveur sous stress Minecraft réaliste |
| Score matériel | 20% | Capacités matérielles brutes (mémoire, disque, multicœur) |
Monocœur et gameplay représentent ensemble 80% du score car Minecraft est fondamentalement un jeu monothread. Le disque le plus rapide du monde n'aidera pas si le CPU ne suit pas le traitement des ticks.
Performance monocœur (40%)
Cette catégorie mesure directement la capacité du serveur à maintenir un TPS stable de 20 sous des charges CPU intensives.
Tests
- Stress redstone — Activation rapide de pistons et propagation de signaux
- Physique des blocs — Blocs qui tombent, flux d'eau et calculs de physique
Ce qui compte le plus
- MSPT (Millisecondes par tick) est la métrique principale. Contrairement au TPS qui plafonne à 20, le MSPT montre la vraie marge : un serveur à 20 TPS avec 10ms MSPT a 40ms de marge, tandis que 20 TPS avec 48ms MSPT est à la limite.
- La performance dans le pire cas est fortement pondérée. Nous regardons les percentiles (P1, P5, P95, P99) pas seulement les moyennes. Un serveur fluide 99% du temps mais qui gèle 200ms chaque minute aura un score plus bas qu'un serveur constant à 30ms.
- La stabilité est récompensée. Une faible variance du TPS et MSPT sur la durée du test rapporte des points bonus.
Score gameplay (40%)
C'est ici que le vrai gameplay Minecraft est simulé. Le plugin crée des scénarios réels en jeu et mesure comment le serveur les gère.
Sous-catégories
Exploration
- Vitesse et débit de chargement des chunks
- Performance du tick des chunks sous charge
- Vitesse de mise à jour du moteur d'éclairage
Entités
- Pathfinding de l'IA des mobs
- Débit de spawn des entités
- Performance avec des centaines d'entités actives
Méchaniques — la sous-catégorie gameplay la plus importante
- Débit de transfert des hoppers
- Calculs d'explosions (réactions en chaîne TNT)
- Tick des tile entities (fours, hoppers, etc.)
- Performance de sauvegarde du monde sous charge
- Croissance des cultures et arbres (traitement du bone meal)
Pourquoi les méchaniques sont les plus pondérées
Les interactions mécaniques sont ce que les joueurs font réellement sur les serveurs survival et techniques. Un serveur qui gère bien le chargement de chunks mais s'étouffe sur les chaînes de hoppers n'est pas utile pour un SMP typique.
Métriques spécifiques aux tests
Chaque test gameplay mesure ce qui compte vraiment pour cette opération :
- Chargement de chunks mesure les chunks par seconde, pas juste le TPS
- Test hopper mesure les items transférés par seconde
- Test explosion mesure les blocs détruits par seconde
- Sauvegarde du monde mesure le débit d'écriture et l'impact TPS
TPS et MSPT servent d'indicateurs secondaires pour vérifier que le serveur ne souffrait pas pendant le test.
Score matériel (20%)
Capacités brutes du système indépendantes de la charge Minecraft :
Mémoire — La métrique matérielle la plus impactante pour Minecraft
- Débit de lecture/écriture séquentiel et aléatoire
- Latence mémoire
- L'accès aléatoire est le plus pondéré car les patterns d'accès aux données de monde de Minecraft sont largement aléatoires
E/S disque
- Débit d'E/S séquentiel et aléatoire
- Latence au 99e percentile (pire cas)
- IOPS (opérations d'E/S par seconde)
Multicœur
- Débit de charge parallèle
- Efficacité de mise à l'échelle des cœurs
- Bonus pour plus de cœurs (utile pour les fonctions async de Paper, le GC, les plugins)
Pourquoi le matériel ne représente que 20%
Parce que Minecraft est monothread. Un serveur avec un NVMe ultra-rapide et 128 Go de RAM mais un CPU faible en monocœur aura quand même un mauvais TPS.
Multiplicateurs
Après le calcul du score de base, plusieurs multiplicateurs l'ajustent pour refléter les conditions réelles :
Durée
Combien de temps le benchmark a pris. Les serveurs plus rapides finissent plus vite, ce qui est en soi un indicateur de performance. Les complétions très lentes (>20 minutes) reçoivent une pénalité.
Garbage Collection
Les pauses GC gèlent le thread principal du serveur. Le système de scoring pénalise :
- La surcharge GC élevée (temps de pause en % du temps total)
- Les longues pauses individuelles (>100ms)
- La fréquence élevée de pauses (beaucoup de petites pauses)
C'est pourquoi le tuning JVM compte — un GC bien configuré peut faire la différence entre un rang B et un rang A.
Stabilité
La cohérence sur l'ensemble du benchmark. Mesurée par :
- L'écart-type du TPS sur tous les tests
- L'écart-type du MSPT
- La cohérence inter-tests (le TPS est-il similaire entre redstone, chargement de chunks et IA des mobs ?)
Des résultats incohérents suggèrent une interférence externe (autres processus, throttling CPU, bruit de l'hébergement mutualisé).
Synergie
Un bonus pour des performances équilibrées. Un serveur qui score bien dans les trois catégories obtient un bonus, tandis qu'un qui excelle en matériel mais échoue en gameplay reçoit une pénalité.
Tests échoués
Chaque test qui échoue ou produit des données invalides applique une pénalité cumulative.
Badges de rang
Le score final correspond à une lettre de rang :
| Rang | Description |
|---|---|
| SS | Exceptionnel — matériel dédié haut de gamme avec tuning parfait |
| S | Excellent — matériel haut de gamme, bien configuré |
| A | Très bon — performances solides dans toutes les catégories |
| B | Bon — au-dessus de la moyenne, marge d'optimisation |
| C | Moyen — hébergement mutualisé typique ou matériel milieu de gamme |
| D | En dessous de la moyenne — problèmes de performance notables |
| E | Faible — goulets d'étranglement significatifs |
| F | Critique — problèmes de performance majeurs |
Points clés à retenir
- Le MSPT compte plus que le TPS — Le TPS plafonne à 20, le MSPT montre la vraie image
- Le pire cas compte plus que la moyenne — Les pics de lag tuent l'expérience joueur
- La stabilité est récompensée — Un TPS constant de 18 bat un TPS erratique de 20-puis-12
- Le gameplay réel > les benchmarks synthétiques — Les tests utilisent de vraies mécaniques Minecraft
- Le tuning GC est de la performance gratuite — Des flags JVM appropriés peuvent significativement améliorer votre score
- Le matériel aide mais ne domine pas — 80% du score dépend du CPU monocœur et du gameplay
- L'équilibre est valorisé — Un serveur polyvalent surpasse celui avec une seule force