Résoudre le lag d'un serveur FiveM : d'OneSync aux scripts lourds

Rien ne gâche une soirée roleplay aussi vite qu'un serveur qui saccade : des voitures qui se téléportent, un inventaire qui met des secondes à s'ouvrir, des PNJ figés sur le trottoir. La bonne nouvelle, c'est que le lag FiveM a presque toujours une cause identifiable. La mauvaise : cette cause se trouve rarement là où vous la cherchez en premier.

Une distinction préalable vous épargne des heures de recherche. Des FPS bas chez les joueurs sont un problème client : maps lourdes, trop de props, PC modestes. Le rubberbanding, les events lents et les actions qui n'arrivent qu'après plusieurs secondes sont généralement côté serveur — et c'est la partie que vous, en tant qu'administrateur, maîtrisez vous-même.

Mesurez d'abord, devinez ensuite

La plus grande erreur possible est de désactiver directement des resources parce que quelqu'un sur Discord a crié que le script X était lourd. Commencez par les chiffres. txAdmin, le panneau standard de FiveM, affiche sur le tableau de bord un graphique de performance : le temps dont votre serveur a besoin par tick. Si ce graphique reste bien dans le vert, le processus serveur est sain et le problème se situe plutôt côté clients ou réseau. Si vous voyez des pics qui coïncident avec les plaintes de vos joueurs, vous savez avec certitude qu'il faut chercher côté serveur.

Regardez aussi dans la console du serveur. FiveM signale lui-même quand un tick dure trop longtemps avec des « hitch warnings », y compris le nombre de millisecondes que le tick a coûté. Un hitch isolé au démarrage est normal ; une console pleine de hitch warnings pendant les heures de pointe est une piste concrète.

Notez enfin quand le lag survient. Uniquement le soir avec beaucoup de joueurs en ligne ? Alors quelque chose s'adapte mal au nombre de joueurs — pensez aux events déclenchés par joueur ou aux requêtes de base de données qui s'accumulent. Perceptible aussi à cinq joueurs ? Alors une resource ou une requête est structurellement lente, et c'est en fait une bonne nouvelle : celle-là, vous la trouverez plus vite.

OneSync : plus de joueurs, plus de travail serveur

OneSync déplace la synchronisation des entités — véhicules, PNJ, objets — des clients vers le serveur. Vous pouvez ainsi dépasser largement la limite de slots classique et le serveur prend la main sur ce que chaque joueur voit : les entités bien hors de portée sont « cullées » et ne sont plus synchronisées.

C'est en grande partie un gain, mais sachez ce que vous échangez. Tout ce travail de synchronisation atterrit sur le processeur de votre serveur et croît avec chaque joueur supplémentaire. Un serveur qui tourne sans accroc à trente joueurs peut atteindre son plafond à soixante sans qu'un seul script n'ait changé. Par ailleurs, certains très vieux scripts de l'ère pré-OneSync se comportent bizarrement : ils supposent que chaque entité existe pour tout le monde, ce qui n'est plus vrai avec le culling.

Désactiver OneSync n'est donc pas une vraie astuce anti-lag, quoi qu'en disent certains forums. En revanche : plus votre nombre de slots est élevé, plus les performances single-core et des scripts bien écrits pèsent dans la balance.

Traquer les scripts lourds

De loin la majorité du lag côté serveur provient de resources mal écrites. Voici comment trouver les coupables :

• resmon : ouvrez dans la console F8 la commande resmon. Vous voyez par resource combien de millisecondes elle coûte par frame. Tout ce qui score structurellement haut alors qu'il ne se passe rien mérite un regard critique.
• Le profiler : pour le côté serveur, FiveM dispose d'un profiler intégré. Avec profiler record 500 vous enregistrez cinq cents ticks et avec profiler view vous voyez par resource et par fonction où le temps s'accroche.
• La méthode par dichotomie : pas envie de profilers ? Désactivez sur un serveur de test la moitié de vos resources et regardez si le lag disparaît. Répétez avec la moitié suspecte. En quelques tours, vous tenez le coupable.

Avec resmon, faites toutefois attention à ce que vous mesurez : côté client vous voyez surtout ce qu'une resource coûte à votre propre jeu, tandis que le profiler côté serveur montre ce que subit le processus serveur. Un script peut sembler inoffensif côté client et boucher quand même le tick côté serveur — ou l'inverse. Mesurez donc des deux côtés avant de tirer des conclusions.

Les pécheurs classiques : des boucles qui tournent à chaque frame sans temps d'attente, des scripts qui itèrent en continu sur tous les joueurs ou entités, et des events envoyés à tous les clients à chaque petite action. Les scripts payants populaires n'y sont pas immunisés non plus — jugez sur les mesures, pas sur la réputation ou le prix.

Important d'être honnête : parfois la solution n'est pas agréable. Un script adoré qui démolit manifestement votre tickrate doit être mis à jour, remplacé ou réécrit. Il n'existe aucune variable serveur qui compense du code mal écrit.

La base de données, frein silencieux

Presque chaque serveur roleplay dépend d'une base de données MySQL via un connecteur comme oxmysql. Si l'ouverture des inventaires ou la sauvegarde des joueurs est lente alors que votre graphique de performance reste vert, cherchez ici.

• Requêtes lentes : activez le slow query log de MySQL et regardez quelles requêtes ressortent. Il manque souvent simplement un index sur une colonne constamment interrogée, comme l'identifiant du joueur.
• Trop de requêtes : certains scripts sauvegardent le personnage complet ou tout l'inventaire à chaque petite modification. À dix joueurs vous ne remarquez rien, à cinquante si.
• Distance : si votre base de données tourne à un autre endroit que votre serveur de jeu, vous payez de la latence réseau à chaque requête. Gardez-les proches, de préférence sur la même machine ou le même réseau, et sur du stockage rapide comme du NVMe.
• Scripts en attente : certains scripts plus anciens attendent de manière bloquante la réponse de la base de données avant de continuer. Chaque requête lente immobilise alors immédiatement une partie de votre serveur. Les connecteurs et scripts récents font cela plus proprement, donc mettre à jour les resources obsolètes est doublement rentable.

Matériel : la vitesse single-core l'emporte

Le gros du travail de synchronisation et de script d'un serveur FiveM tourne en grande partie sur un seul thread. Un processeur à haute fréquence et fortes performances single-core fait donc plus pour votre tickrate qu'une montagne de cœurs supplémentaires. La mémoire détermine surtout combien de resources et de joueurs vous pouvez accueillir, et un stockage rapide aide votre base de données et vos temps de chargement.

Chez MC-Node, les serveurs FiveM tournent sur du matériel dédié avec stockage NVMe et protection anti-DDoS dans le datacenter Previder à Hengelo — donc un ping bas pour les joueurs néerlandais et belges. Toutes les offres sont résiliables mensuellement, ce qui vous permet de commencer petit et de ne monter en gamme que quand vos mesures le demandent :

Soyons honnêtes : une offre plus lourde ne répare pas des scripts mal écrits. Mais si, avec un serveur bien rangé, vous butez encore structurellement contre votre plafond, alors l'upgrade est la suite logique. Comparez les options dans les offres FiveM de MC-Node et passez à la taille au-dessus — grâce à la résiliation mensuelle, vous n'êtes engagé nulle part.

Votre plan d'action en bref

1. Confirmez avec le graphique txAdmin et les hitch warnings que le problème est vraiment côté serveur.
2. Lancez resmon et le profiler pendant les heures de pointe, pas à trois heures du matin sur un serveur vide.
3. Attaquez-vous à la resource la plus lourde : mise à jour, remplacement ou réécriture.
4. Vérifiez la base de données : requêtes lentes et index manquants.
5. Scripts et base de données en ordre, mais toujours bloqué ? Alors seulement, le matériel est la réponse.

Qui travaille dans cet ordre résout la plupart du lag en une soirée — et sait en plus avec certitude qu'un éventuel upgrade n'est pas un pansement coûteux, mais un choix ciblé.