Folia - Multithreading régionalisé pour votre serveur
Folia (PaperMC/Folia)
Fork de Paper qui ajoute le multithreading régionalisé au serveur dédié.
Si vous administrez un grand serveur Minecraft et voyez votre TPS chuter chaque fois que quelqu'un explore de nouveaux chunks ou lors des pics de joueurs, Folia pourrait être la réponse que vous cherchiez. Ce fork basé sur Paper réimagine complètement la façon dont les serveurs Minecraft gèrent le calcul en divisant le monde en régions indépendantes, chacune fonctionnant sur son propre thread. Au lieu d'un seul thread principal qui peine à tout gérer à la fois, Folia permet à vos cœurs de processeur de faire du travail réellement parallèle.
Qu'est-ce que Folia
Folia n'est pas un mod. Ce n'est pas un plugin. C'est une réécriture complète du serveur Paper qui supprime entièrement le concept de thread principal. À la place, les chunks proches sont regroupés en "régions", et chaque région exécute sa propre boucle de tick sur le pool de threads. Pensez-y comme donner à différentes parties de votre monde leur propre processeur indépendant plutôt que de forcer un seul thread à tout gérer.
L'architecture a de l'importance car elle change la façon dont votre serveur évolue.
Paper gère bien les serveurs avec des millions de joueurs dans sa conception monotâche, mais une fois que vous atteignez ce prochain niveau d'échelle - des centaines de joueurs dispersés dans un monde énorme - des goulots d'étranglement apparaissent. Folia n'essaie pas d'extraire plus d'un seul thread. Au lieu de cela, il change fondamentalement le problème.
Pourquoi vous voudriez ceci
Les grands serveurs dispersés bénéficient le plus. Les réseaux Skyblock où les joueurs ont des îles flottantes éparpillées dans les dimensions, les mondes de survie massifs, les serveurs RPG personnalisés avec des donjons distribués - c'est là que Folia brille. Si vos joueurs se regroupent dans une zone de spawn, vous ne verrez pas les mêmes gains de performance. Mais pour un SMP de 200+ joueurs où les gens explorent dans différents quadrants, la différence est considérable.
Je dois le mentionner dès le départ : ce n'est pas un remplacement direct.
Vos plugins doivent être réécrits pour l'environnement multithreadé de Folia. C'est le vrai coût. Mais si vous êtes à l'échelle où vous le considérez, votre écosystème de plugins est probablement déjà personnalisé. Les plugins standard de Paper qui ne supposent pas un thread principal vont se casser immédiatement sous Folia.
La récompense est véritable cependant. Avec une configuration appropriée, vous obtenez de véritables améliorations de performance qui s'adaptent à votre nombre de cœurs CPU. Ce n'est pas réalisable avec Paper standard.
Installation et configuration de base
Tout d'abord, téléchargez la dernière version depuis la page de téléchargement de PaperMC. Depuis 2026, Folia supporte les versions modernes de Minecraft (1.20.4 et versions ultérieures). Téléchargez le fichier jar dans votre répertoire serveur :
<! - gh-code-start - >wget https://api.papermc.io/v2/projects/folia/versions/latest/builds/latest/downloads/folia-latest.jar
mv folia-latest.jar folia.jarEnsuite, vous devez accepter l'EULA dans votre fichier eula.txt. Démarrez le serveur une fois pour générer vos fichiers de configuration :
<! - gh-code-start - >java -Xmx30G -Xms30G -jar folia.jar noguiArrêtez-le (il créera la configuration folia.yml), puis vous entrez dans le vrai travail : la configuration des threads. Ce n'est pas juste "augmentez les threads et c'est bon". La documentation de PaperMC recommande de pré-générer votre monde avant de passer à la production, ce qui réduit considérablement la surcharge de chargement des chunks.
Configuration des threads - Le vrai défi
C'est là que la plupart des gens se trompent. Votre folia.yml a un paramètre `threaded-regions.threads`. Ne le mettez pas juste au maximum. La directive du projet lui-même : allouez des threads pour netty IO (environ 4 pour 200-300 joueurs), threads IO du système de chunks (environ 3 pour 200-300 joueurs), workers du système de chunks si pré-générés (environ 2 pour 200-300 joueurs), puis utilisez les cœurs restants jusqu'à 80 % d'allocation totale pour les threads de tick.
Sur une machine avec 32 cœurs servant 500 joueurs, vous alloueriez approximativement :
- Netty IO : 8 threads
- IO du système de chunks : 6 threads
- Workers du système de chunks : 4 threads
- Threads de tick : cœurs restants jusqu'à 80 % (environ 10 threads)
Vous ne laissez pas 100 % d'allocation car les plugins et les tâches de fond inattendues engendreront leurs propres threads et planteront le serveur. Le plafond de 80 % est une limite de sécurité qui a vraiment de l'importance.
Même alors, c'est un point de départ. Surveillez votre utilisation réelle des threads sous charge et ajustez. Le fichier folia.yml contient des commentaires détaillés pour chaque option.
Fonctionnalités principales qui fonctionnent
Isolation des régions. Chaque région fait un tick indépendamment à 20 TPS. Un pic de lag dans une région ne se propage pas aux autres. Si votre système de donjon est mal optimisé, il ne ruinera pas la performance de votre zone de spawn.
Mise à l'échelle appropriée des threads. Contrairement à l'approche de thread pool de plugins de Paper (qui met toujours en goulet d'étranglement les opérations critiques de tick), les régions de Folia exécutent la logique de tick en parallèle. Plus de cœurs se traduit réellement par plus de traitement de ticks. La mise à l'échelle n'est pas linéaire, mais elle est réelle.
Chargement de chunks asynchrone. L'I/O des chunks se fait en dehors des threads de région. Vous n'aurez pas les gels aléatoires que les serveurs monotâches rencontrent quand les lectures de stockage augmentent.
Il y a aussi un support natif pour l'optimisation des chunks côté serveur, la mise en cache des chunks pré-générés, et les limites de mémoire configurables par région. Honnêtement, la profondeur des fonctionnalités est impressionnante si vous êtes disposé à creuser dans la documentation.
Ce qui va casser et comment le gérer
La plupart des plugins supposent qu'ils sont sur un thread principal et qu'ils peuvent lire/écrire l'état du monde en toute sécurité sans synchronisation. Ils ont tort sur Folia. Si un plugin fait quelque chose comme "vérifier si le bloc X est de la pierre, puis le mettre en air", cette condition de course peut se produire sur les threads d'une façon qui ne se produirait jamais sur Paper. Attendez-vous à des échecs de plugins.
Quelques détails :
- La téléportation entre régions implique une complexité supplémentaire et peut causer des interblocages si les plugins ne font pas attention
- Les vérifications des bordures du monde sont conscientes des régions et peuvent se comporter différemment que prévu
- Les minuteurs et les tâches programmées doivent être sûrs pour les régions pour éviter la corruption
- Le suivi des entités à travers les limites des régions nécessite des mises à jour de plugins
Les docs de Folia listent les modèles incompatibles explicitement. Si vous évaluez les plugins pour la compatibilité, vérifiez s'ils manipulent directement la logique de tick ou supposent un accès monotâche aux données des chunks.
Quand Folia a du sens
Vous avez une machine avec 16+ cœurs. Votre serveur va régulièrement atteindre 200+ joueurs concurrents. Vos joueurs sont géographiquement dispersés (pas tous au spawn). Vous avez soit une infrastructure de plugins personnalisée, soit vous êtes disposé à porter les plugins existants.
Ces quatre conditions ? Vous êtes un candidat.
Vous exécutez 50 joueurs sur un VPS avec 8 cœurs ? Restez avec Paper. Les gains ne justifieront pas le problème de compatibilité. Vous exécutez un SMP de 100 joueurs où tout le monde traîne au spawn ? Folia aide, mais pas aussi dramatiquement que sur un serveur dispersé.
Mais si vous construisez la prochaine génération de communautés Minecraft multijoueur sérieuses, Folia est l'endroit où le plafond de performance est réellement plus élevé. Les joueurs avec des skins comme celui d'adderall_abuser, celui d'ironmouse, et d'autres membres actifs de la communauté sur des serveurs massifs explorent déjà cet espace. Consultez les communautés de streaming et les grands projets de survie sur Modrinth - vous verrez Folia apparaître plus souvent.
Alternatives dignes de considération
Paper. Toujours l'étalon-or pour la plupart des serveurs. Stable, bien compris, énorme écosystème de plugins. Si Folia semble excessif, les fonctionnalités d'optimisation de Paper (chargement de chunks asynchrone, ticks d'IA d'entité réduits, etc.) pourraient suffire.
Purpur. Un fork de Paper avec des optimisations supplémentaires par joueur. Mieux pour les serveurs où l'expérience des joueurs varie énormément (certains AFK, certains explorant activement). Moins de changement d'architecture que Folia, des gains de performance plus ciblés.
Fabric Server. Si vous avez besoin du support des mods (pas des plugins), l'écosystème Fabric est en fait assez solide pour les serveurs maintenant. Pas multithreadé de la même façon, mais léger et rapide.
La vérité honnête : Folia est spécialisé. C'est pour un problème spécifique à une échelle spécifique. Pour tout le monde d'autre, Paper avec une configuration réfléchie est toujours le bon choix.
<! - gh-polish-start - > <! - gh-polish-end - >
