Performances et lagUne extension qui journalise chaque bloc cassé, chaque connexion, chaque transaction d'économie écrit sans arrêt. Pointez-la vers un fichier .db au lieu d'un vrai serveur de base de données, et chacune de ces écritures peut finir par faire la queue derrière le fil principal — ce qui est une façon bien détournée de perdre du TPS pour une fonctionnalité que personne n'appellerait critique pour la performance.
Le mécanisme
SQLite n'est pas un serveur — c'est une bibliothèque qui lit et écrit un fichier plat directement, sans processus séparé gérant l'accès. Pour garder ce fichier cohérent, le mode par défaut de SQLite n'autorise qu'un seul écrivain à la fois : pendant qu'une écriture a lieu, toute autre connexion voulant écrire doit attendre qu'elle se termine, et par défaut même les lecteurs peuvent être bloqués.
Une extension qui journalise les changements de blocs, le chat ou les transactions d'économie écrit sans arrêt, et chacune de ces écritures doit obtenir ce verrou de fichier. Si les appels à la base de données de l'extension se font sur le fil principal plutôt que sur un fil d'arrière-plan, cette attente devient une attente que fait tout le jeu — chaque joueur, chaque entité, gelés le temps d'une écriture disque.
SQLite face à un serveur MySQL
SQLite (fichier .db) | MySQL | |
|---|---|---|
| Ce que c'est | Une bibliothèque liée dans l'extension, écrivant directement dans un fichier | Un processus serveur séparé, accédé via une connexion |
| Écritures concurrentes | Une à la fois, verrouillée par fichier | Plusieurs, avec un verrouillage au niveau des lignes dans InnoDB |
| Où l'attente se produit | Le fil qui a émis l'écriture — souvent le fil principal | La propre connexion de l'extension, qu'une extension bien écrite garde hors du fil principal |
| Convient à | Un outil solo, un serveur personnel à faible trafic | Toute extension journalisant plus que l'occasionnel événement |
Beaucoup d'extensions qui se comportent parfaitement avec MySQL utilisent SQLite par défaut parce qu'il ne demande aucune configuration — et la même extension, les mêmes réglages, le même serveur, peuvent passer d'imperceptible à une chute de TPS visible dès que le volume d'écritures augmente, sans que rien n'ait changé dans le code même de l'extension. Le moteur de base de données est la variable, pas la qualité de l'extension.
Sortir une extension de SQLite
- Vérifiez la config de l'extension pour une section stockage ou base de données
Presque toute extension capable d'utiliser MySQL expose des champs hôte, port, nom de base, utilisateur et mot de passe — souvent commentés ou réglés sur SQLite par défaut.
- Pointez-la vers la base MySQL incluse dans votre forfait
Créez-en une depuis l'onglet Bases de données si besoin, et utilisez l'adresse locale affichée là plutôt qu'une IP publique.
- Redémarrez une fois, et confirmez dans le propre journal de démarrage de l'extension
La plupart affichent une ligne confirmant à quel moteur elles se sont connectées. Cette ligne est la preuve que le changement a pris, pas seulement que le fichier de config a changé.
Le journal de l'extension confirme une connexion MySQL, et le TPS reste stable pendant l'activité qui causait auparavant une chute — casse de blocs en masse, une boutique animée, une vague de connexions.