Meridian : avancement, tests et mesures

Où en est le projet

2,5 ×moins de processeur pour le proxy avec l’optimisation (pull request #160) MesuréMesuré avant et après sur le même banc : 2,6 fois à 500 joueurs typiques, 2,3 fois à 1 000.

1 000bots-joueurs typiques tenus par un seul proxy sur un seul PC MesuréAvec des bots et des serveurs de jeu synthétiques ; avec de vrais serveurs Horizon, les tests sont en cours.

0joueur perdu dans ce test MesuréUne heure à 1 000 joueurs typiques.

Meridian est un proxy qui fonctionne : il dirige les joueurs, répartit la charge et les déplace d’un serveur à l’autre sans écran de chargement. Il a tenu 1 000 bots-joueurs typiques sur un seul PC, avec 0 joueur perdu. Une optimisation qui réduit l’usage du processeur d’environ 2,5 fois a été fusionnée (pull request #160).

Testé avec de vrais serveurs de jeu et de vrais clients sur un vrai réseau (3 joueurs), puis avec jusqu’à 1 500 bots.
Pas encore mesuré : la vitesse propre du serveur de jeu (le TPS, c’est-à-dire le nombre de ticks, ou pas de calcul, par seconde) avec beaucoup de joueurs. Voir « Pas encore testé ».

Meridian est un proxy (un intermédiaire placé entre les joueurs et les serveurs) pour Horizon, une version de Minecraft Java Edition écrite en Rust. Les joueurs se connectent au proxy, qui envoie chacun vers l’un des serveurs placés derrière lui, et peut déplacer un joueur vers un autre serveur sans écran de chargement.

Avec l’équipe Horizon

Meridian est développé en public, comme un projet distinct de Horizon. L’équipe Horizon, les mainteneurs de Horizon, a donné des indications sur la façon de s’y prendre, et c’est elle qui décide de ce qui entre dans Horizon lui-même. Ses demandes sont sur un ticket public de Horizon : de petites pull requests, une à la fois. Ces indications ne valent pas approbation de Meridian.

Voir ticket #7484 de Horizon.

Ce qui a été demandé et ce qui est fait : Feuille de route.

Avant et après l’optimisation

Avant (branche main) (commit 57930e6) · Après (les écritures d’une même lecture sont groupées) (commit c38a01e (fusionné, #160))

Avec des serveurs de jeu qui envoient ensemble les paquets d’un tick (un pas de calcul de 50 ms), comme le font les vrais serveurs, le proxy dépense maintenant environ 2,5 fois moins de processeur par paquet : 1 000 joueurs typiques demandent environ 2,6 cœurs au lieu de 6,2.

Processeur pour 1 000 joueurs

sur les 8 cœurs que le proxy peut utiliser

Avant6,17 cœurs

Après2,62 cœurs

2,4 fois moins de cœurs

Mesuré

Coût d’un paquet

500 joueurs typiques

Avant20,31 µs

Après7,92 µs

2,6 fois moins de processeur

Mesuré

Les 1 % d’allers-retours les plus lents (p99)

500 joueurs typiques

Avant15,09 ms

Après2,67 ms

5,7 fois plus bas

Mesuré

Paquets envoyés d’un coup

à chaque joueur

Avant1 paquet

Après12,5 à 17,1 paquets

12 à 17 paquets à chaque écriture au lieu de 1

Mesuré

Mémoire par joueur

le prix du changement

Avant524 Ko

Après532 Ko

+1,3 % (5 % admis)

Mesuré

Rien n’est perdu pour autant : les mêmes paquets arrivent aux joueurs, aucun joueur n’a été perdu, et la mémoire par joueur reste à environ 1 % de ce qu’elle était.

Quand il n’y a rien à grouper, rien ne change. C’est mesuré sur un seul PC avec des bots et vérifié avec un vrai serveur ; c’est fusionné (pull request #160).

Chaque mesure, une par une

Processeur par paquet, 500 joueurs typiques

2,6 fois moins de processeur

Avant

20,31 µs Mesuré

Après

7,92 µs Mesuré

des serveurs qui écrivent une fois par tick (toutes les 50 ms), comme les vrais

Processeur par paquet, 1 000 joueurs typiques

2,3 fois moins de processeur

Avant

19,03 µs Mesuré

Après

8,11 µs Mesuré

Cœurs du proxy, 1 000 joueurs typiques

2,4 fois moins de cœurs

Avant

6,17 cœurs Mesuré, à surveiller

Après

2,62 cœurs Mesuré

les 8 threads donnés au proxy : 8 cœurs (le trait sur les barres).

Paquets par écriture vers les joueurs

12 à 17 paquets à chaque écriture au lieu de 1

Avant

1 paquet Mesuré

Après

12,5 à 17,1 paquets Mesuré

avec un vrai serveur de jeu : environ 15 (15,5 mesurés sur le premier scénario de l’essai sur réseau réel)

Mémoire par joueur, 1 000 joueurs typiques

+1,3 % (5 % admis)

Avant

524 Ko Mesuré

Après

532 Ko Mesuré

à 500 joueurs : 514 avant, 499 après. La première version coûtait +19 % ; cela a été corrigé.

Latence p99 à travers le proxy, 500 joueurs typiques

5,7 fois plus bas

Avant

15,09 ms Mesuré

Après

2,67 ms Mesuré

p99 : 99 allers-retours sur 100 sont plus rapides que cette valeur. Le tick du serveur, de 50 ms, fait partie de ces chiffres.

Latence, 1 000 joueurs typiques

non concluant

Avant

pas de chiffre Non concluant

Après

pas de chiffre Non concluant

les bots tournent sur le même PC et étaient la limite

Témoin : des serveurs qui envoient chaque paquet seul témoin

aucun changement

Avant

24,58 µs Mesuré

Après

24,72 µs Mesuré

rien à grouper ici, donc rien ne doit changer : cela montre que le gain vient du seul groupement

Une ligne témoin est un cas où rien ne devrait changer. Elle montre que le gain vient du seul changement.

Combien de joueurs ?

Nous testons avec des bots qui se comportent comme des joueurs, sur un seul PC. Chaque chiffre dit à quel point nous en sommes sûrs :

Mesuré Nous l’avons lancé et compté. Aucun joueur n’a été perdu.
Non concluant Nous l’avons lancé, mais le PC de test était la limite : le résultat ne dit donc rien sur le proxy.
Extrapolé Une estimation à partir du coût d’un joueur. Pas lancé.

Joueurs légers

peu de trafic : 20 petits paquets et 2 chunks (portions de carte) par seconde chacun (le profil du premier test)

Démontré

1 500 joueurs Mesuré

2,39 cœurs de processeur

2,39 cœurs pour le proxy, avant l’optimisation (elle change peu de chose pour un trafic léger)

Non démontré

2 000 joueurs Non concluant

la machine de test était la limite : le proxy lui-même avait de la marge (3,5 cœurs)

Joueurs typiques

restent immobiles ou marchent environ la moitié du temps ; profil construit à partir d’un vrai client (275 petits paquets et 3,5 chunks par seconde chacun)

Démontré

1 000 joueurs Mesuré

2,62 cœurs de processeur

2,62 cœurs avec l’optimisation (commit c38a01e, fusionné dans la pull request #160) ; 6,2 cœurs avant. Sa latence n’a pas pu être jugée : les bots étaient la limite.

Joueurs très actifs

marchent plus de la moitié du temps (le profil de test de charge)

Démontré

500 joueurs Mesuré

6,4 cœurs de processeur

6,40 cœurs avant l’optimisation, avec des serveurs qui écrivent chaque paquet seul ; 1 000 joueurs très actifs n’ont pas été testés

Ce que coûtent 1 000 joueurs typiques

Processeur

2,62 cœurs Mesuré

33 % de 8 cœurs (les 8 threads donnés au proxy sur le PC de test).

6,2 cœurs avant l’optimisation ; en mode en ligne (chiffrement), environ 1,4 cœur de plus est une estimation

Mémoire

0,53 Go Mesuré

7 % de 8 Go (le VPS).

Débit, dans chaque sens

660 Mbit/s Mesuré, au-dessus de la limite

132 % de 500 Mbit/s (la ligne Internet).

environ 83 Mo/s vers les joueurs, et autant des serveurs vers le proxy ; compté avant compression, donc sur le câble c’est moins

Ce que cela veut dire pour des machines plus petites

Sur une ligne de 500 Mbit/s : environ 500 à 600 joueurs typiques Extrapolé
Sur le VPS (4 cœurs partagés) : environ 300 à 500 joueurs typiques Extrapolé

Les machines

Le PC de test

Windows 11
Intel i9-14900KF : 8 cœurs rapides (2 threads chacun) + 16 cœurs économes
64 Go de mémoire
Le proxy disposait de 8 threads (4 cœurs rapides) ; les bots utilisaient les autres cœurs

Le VPS (serveur loué)

Une machine virtuelle KVM, sous Linux (Ubuntu 26.04 LTS, noyau 7.0)
4 cœurs virtuels (1 thread chacun), présentés comme un Intel Core Processor (Haswell) à 3,0 GHz ; le modèle exact est caché par l’hébergeur
8 Go de mémoire (7,6 Gio utilisables), pas de swap (mémoire d’échange)
Disque de 75 Go, NVMe d’après l’offre de l’hébergeur (le disque virtuel ne le dit pas)
Réseau : jusqu’à environ 3 Gbit/s d’après l’offre de l’hébergeur ; non mesuré
Les cœurs sont partagés : aucun signe de gêne causée par les autres machines au repos (0,0 % de temps volé), pas testé en charge

La ligne Internet

500 Mbit/s en réception et en envoi (annoncé)

Tests sur réseau réel

De vrais serveurs de jeu, de vrais clients de jeu, un vrai réseau entre eux. Peu de joueurs, mais pas de bots et aucun raccourci.

essai sur réseau réel (VPS + PC), 8 novembre

Vrais joueurs dans le test

3 joueurs Mesuré

Déplacements d’un serveur à l’autre, et retour

plus de 50 déplacements entre deux serveurs, tous réussis Mesuré

Durée en secondes : 1,4 à 2,1

18 + 34 vus depuis les clients, 20 + 34 vus depuis le proxy.

Un serveur qui s’arrête avec des joueurs dessus

3 sur 3 déplacés ailleurs à l’arrêt du serveur B Mesuré

Vitesse d’évacuation des joueurs

1,5 s par joueur, un toutes les 2 s Mesuré

Un serveur qui s’arrête d’un coup

3 joueurs sur 3 ont été renvoyés vers l’autre serveur, sans retourner à l’écran-titre Mesuré

Durée en secondes : 0,011 à 0,123 (côté proxy)

Un joueur était encore en cours de déplacement quand le serveur l’a expulsé : le correctif de cette semaine l’a rattrapé (123 ms).

Un serveur qui plante

3 joueurs sur 3 ont été renvoyés vers l’autre serveur après l’arrêt brutal du processus du serveur Mesuré

Durée en secondes : 0,021 à 0,025 (côté proxy), 0,9 à 1,7 vu à l’écran

Reconnexions rapides

5 reconnexions rapides sur 5 ont abouti, sans erreur Mesuré

Le client est revenu sous un autre nom : cela vérifie donc la reconnexion, pas les données d’un joueur qui revient.

Paquets groupés à chaque écriture

environ 15 paquets par écriture Mesuré

15,5 mesurés sur le premier scénario.

Mémoire du proxy

11 Mo avec 3 joueurs au repos ; 67 à 105 Mo au repos après 20 à 60 transferts Mesuré, à surveiller

Un palier, pas une montée continue (elle est retombée à 91 Mo après d’autres transferts). Pas encore comparé à l’ancien proxy.

Un vrai serveur sur le VPS, un sur le PC, 3 vrais clients, proxy final. Non testé ici : la vitesse propre du serveur de jeu (TPS, ticks par seconde) avec beaucoup de joueurs.

Charge sur un vrai serveur Horizon

Des bots, pas des personnes, et pas de réseau : 50 bots qui volent et explorent, sur un vrai serveur Horizon, le tout sur un seul PC. Les mêmes bots avec les mêmes graines, d’abord connectés directement au serveur, puis à travers le proxy.

Test L2-1, 8 novembre 2026 : 5 minutes de mise en route, puis 10 minutes mesurées.

50 joueurs sur un vrai serveur : la même vitesse avec et sans le proxy.

Mesure	En direct	À travers le proxy
Vitesse du serveur, moyenne	20 TPS Mesuré au plus bas 19,95	20 TPS Mesuré au plus bas 19,93
Tick du serveur, moyenne	16,9 ms Mesuré	17,1 ms Mesuré
Tick du serveur, 95e centile	19,5 ms Mesuré	19,9 ms Mesuré
Processeur du serveur	0,4 cœur Mesuré	0,44 cœur Mesuré
Mémoire du serveur	830 à 871 Mo Mesuré	823 à 863 Mo Mesuré
Chunks reçus par les bots	315 766 chunks Mesuré	315 710 chunks Mesuré
Données reçues par les bots	3 545 Mo Mesuré	3 550 Mo Mesuré
Bots perdus, sur 50	0 bot Mesuré	0 bot Mesuré
Processeur du proxy	–	0,21 cœur Mesuré
Mémoire du proxy	–	92 Mo Mesuré

Un seul essai de chaque, 50 bots sur un serveur, le tout sur un seul PC (pas de réseau). Le serveur n’a pas été poussé à sa limite, et les bots volent en mode créatif : ni minage, ni construction, ni combat. La latence ajoutée n’est pas mesurée ici : le ping du serveur compte en millisecondes entières.

Feuille de route

Ce qui est fait et validé, ce qui est en cours et ce qui est prévu.

Une tâche n’est marquée « faite » que lorsqu’elle est terminée et validée (fusionnée et vérifiée), avec une preuve publique et sa date.

Avec l’équipe Horizon · La feuille de route de Meridian

Avec l’équipe Horizon

Demandé par l’équipe Horizon et validé

Une demande est validée quand sa pull request est fusionnée dans Horizon.

Fait

Le transfert sans coupure, en une pile de pull requests

Un joueur passe d’un serveur Horizon à un autre sans écran de chargement. La pile de sept pull requests a été relue et fusionnée par l’équipe Horizon entre le 4 et le 5 novembre.

Preuves : pull request #8693 de Horizon, pull request #8700 de Horizon, pull request #8709 de Horizon, pull request #8716 de Horizon, pull request #8730 de Horizon, pull request #8735 de Horizon, pull request #8742 de Horizon · validé le 5 novembre 2026

Fait

Un serveur donne son état au proxy (transfer-status)

Un serveur Horizon indique à un proxy combien de joueurs il a et s’il en accepte d’autres, avant qu’on lui en envoie.

Preuve : pull request #10527 de Horizon · validé le 6 novembre 2026

Fait

Pas de déplacement vers un serveur plein ou en arrêt

Un serveur Horizon refuse un joueur qu’on lui envoie quand il est plein ou en train de s’arrêter, et le joueur reste où il était.

Preuve : pull request #11428 de Horizon · validé le 7 novembre 2026

Fait

Un serveur qui s’arrête attend le proxy

Avant de s’arrêter, un serveur Horizon laisse quelques secondes à un proxy pour déplacer ses joueurs vers un autre serveur.

Preuve : pull request #11713 de Horizon · validé le 8 novembre 2026

Fait

Les passagers tournent comme dans le jeu original

Une correction dans Horizon pour les joueurs sur une monture ou un véhicule, fusionnée par l’équipe Horizon.

Preuve : pull request #12260 de Horizon · validé le 8 novembre 2026

Fait de notre côté, en attente de la réponse de l’équipe

Ce que l’équipe Horizon a demandé sur le ticket, fait et vérifié par nous ; sa réponse reste à venir.

Fait

Le test de passage de relais sur la branche principale de Horizon

Le test de bout en bout du déplacement d’un joueur entre deux serveurs Horizon, lancé sur la branche principale de Horizon comme demandé : 31 vérifications sur 31, à 3 essais sur 3.

Preuve : les résultats, publiés sur le ticket · validé le 6 novembre 2026

Fait

Des tests sur un vrai réseau, deux fois

De vrais serveurs Horizon, de vrais clients de jeu et un vrai réseau, les 6 et 7 novembre ; les résultats sont publiés sur le ticket.

Preuves : l’essai du 6 novembre, l’essai du 7 novembre, les essais, en détail · validé le 7 novembre 2026

Fait

Un point d’extension, et les opérateurs des serveurs

Meridian demande à une extension si un joueur peut se connecter, où il va et quelles commandes il peut utiliser, et il lit les opérateurs des serveurs.

Preuves : pull request #137, pull request #144, pull request #145, pull request #120 · validé le 7 novembre 2026

Fait

Un ticket public pour les nouvelles du proxy

Les nouvelles de Meridian vont sur un ticket de son propre dépôt, comme demandé, et plus sur celui de Horizon.

Preuve : ticket #117 · validé le 6 novembre 2026

En attente de la relecture de l’équipe Horizon

Notre seule pull request ouverte dans Horizon : une à la fois, comme demandé.

En cours

Le livre de recettes sur un serveur Paper

Le livre de recettes de Horizon prend les entrées que le serveur envoie, et marche donc sur un serveur Paper. Prête pour la relecture depuis le 8 novembre ; ses vérifications automatiques passent.

Preuve : pull request #12496 de Horizon

Le travail que nous avançons en attendant

Du travail du côté de Meridian, qui ne demande rien à Horizon. Chaque élément est dans la feuille de route plus bas.

En cours