Optimiser les performances de son serveur FiveM

« Ça lag » est le message le plus fréquent sur un serveur FiveM, et aussi le plus vague. Cette page vous apprend à mesurer avant de changer quoi que ce soit : repérer la ressource qui coûte cher, distinguer un problème serveur d’un problème client, et reconnaître le moment où c’est l’offre qui est devenue trop juste. Elle s’adresse à un propriétaire de serveur qui voit des ralentissements et ne sait pas par quoi commencer.

Une règle avant tout le reste : ne changez qu’un paramètre à la fois, et mesurez après. Un serveur FiveM a trop de variables pour attribuer une amélioration à cinq changements simultanés.

Lire resmon et repérer les ressources coûteuses

resmon est le moniteur intégré à FiveM. Il affiche, ressource par ressource, le temps de calcul consommé à chaque image.

Connectez-vous à votre serveur avec le client FiveM.
Ouvrez la console du jeu avec la touche F8.
Tapez resmon 1 puis validez. Un tableau se superpose à l’écran.
Laissez tourner une minute en jouant normalement : entrez dans un véhicule, ouvrez votre inventaire, allez en ville. Les coûts se révèlent à l’usage, pas à l’arrêt.
Triez mentalement par la colonne de temps CPU et notez les trois ressources les plus hautes.
Refermez avec resmon 0.

Ce que resmon mesure est la charge côté client. Les repères communément admis dans la communauté FiveM — ce ne sont pas des seuils CloudFive — situent une ressource au repos à quelques centièmes de milliseconde ; au-delà de 0,5 ms il y a quelque chose à regarder, et une ressource qui dépasse durablement 1 ms pénalise les FPS de tous vos joueurs.

Pour la charge côté serveur, resmon ne suffit pas : utilisez le graphique de performance de txAdmin, qui montre l’évolution du temps de traitement du serveur dans le temps. Un pic à chaque minute pile, par exemple, trahit presque toujours une tâche programmée ou une sauvegarde automatique.

Comprendre les hitches serveur et client

Un hitch est une image que le moteur a mis anormalement longtemps à produire. Le serveur l’écrit dans la console sous la forme d’un avertissement mentionnant un temps en millisecondes.

Il y a deux familles de hitches, et on les confond sans arrêt :

le hitch serveur touche tout le monde en même temps. Les véhicules se téléportent, les PNJ se figent, les joueurs se plaignent à la même seconde. La cause est sur le serveur : un script qui bloque, une requête base de données lourde, une sauvegarde ;
le hitch client ne touche qu’une personne. Son jeu se bloque une demi-seconde, les autres ne voient rien. La cause est sur sa machine ou sur une ressource trop coûteuse pour son matériel.

Deux hitches sont normaux et n’indiquent aucun problème : ceux du démarrage du serveur, pendant le chargement des ressources, et ceux de l’arrivée d’un joueur qui télécharge du contenu.

Régler OneSync et le nombre de slots

Deux lignes de server.cfg déterminent la façon dont le serveur synchronise les joueurs :

set onesync on
sv_maxclients 32

OneSync est le mode de synchronisation moderne de FiveM. Sans lui, sv_maxclients est limité à 32 joueurs. Au-delà, OneSync est obligatoire — et la plupart des frameworks récents le supposent actif de toute façon. Les valeurs acceptées sont on, legacy et off ; on est le choix par défaut pour un serveur neuf, legacy ne sert que pour des ressources anciennes qui n’ont jamais été portées.

Pour sv_maxclients, la question n’est pas « combien FiveM autorise » mais « combien votre offre encaisse ». Les paliers FiveM sont dimensionnés par tranches : environ 16 joueurs sur l’offre Starter, 32 sur l’Essentiel, 64 sur l’Avantage, 96 sur la Performant. Annoncer 128 places sur une offre taillée pour 32 ne crée pas de la capacité, seulement un serveur injouable dès qu’il se remplit. Voir la page FiveM et Combien de RAM pour un serveur FiveM ?.

Optimiser les scripts et les boucles

L’immense majorité des problèmes de performance d’un serveur FiveM vient des scripts installés, pas de la machine. Les causes récurrentes, par ordre de fréquence :

les boucles sans pause. Un script qui fait while true do ... end sans attente consomme en continu. Une boucle qui n’a besoin de réagir qu’une fois par seconde doit attendre une seconde, pas une image ;
les boucles qui dessinent en permanence. Marqueurs au sol, textes 3D, zones de métier affichés à chaque image, même quand le joueur est à deux kilomètres. Un test de distance avant l’affichage divise souvent le coût par dix ;
les requêtes base de données dans une boucle. Chaque requête attend une réponse ; mille requêtes par minute bloquent le serveur. Voir Connecter la base de données ;
le contenu « streamé » en excès. Les packs de véhicules et de vêtements occupent de la mémoire, allongent le temps de connexion des joueurs et font planter les clients quand le volume devient déraisonnable. C’est aussi ce qui remplit votre disque le plus vite ;
les ressources que personne n’utilise. Chaque ensure coûte quelque chose. Les scripts installés « pour essayer » et jamais retirés finissent par peser.

La démarche efficace tient en trois mouvements : retirez la ligne ensure de la ressource la plus coûteuse, redémarrez, mesurez à nouveau. Si le gain est net, cherchez une version à jour ou une alternative mieux écrite — un script à l’abandon depuis trois ans a souvent un remplaçant. Sinon, remettez-la et passez à la suivante. Voir Ajouter des ressources et des scripts.

Quand l’offre devient le facteur limitant

Il arrive un moment où il n’y a plus rien à optimiser. Les signes :

resmon est propre, aucune ressource ne dépasse les repères, et les hitches serveur arrivent quand même dès que le serveur se remplit ;
la mémoire disponible est au plafond en permanence, visible depuis le panel — voir Démarrer, arrêter et redémarrer son serveur pour l’emplacement des compteurs ;
le serveur redémarre tout seul aux heures de pointe : c’est le symptôme classique du manque de mémoire ;
le disque est plein à cause du contenu streamé et des logs.

Dans ces cas, changez de palier plutôt que de continuer à bricoler : Changer de formule conserve vos données. Si vous voulez en plus maîtriser l’environnement complet, Serveur de jeu ou VPS vous dira si le passage en VPS a du sens — et ce qu’il demande en administration.

Si ça ne marche pas

resmon est propre et tout le monde lag quand même. Regardez d’abord status.cloudfive.xyz : si un incident réseau est en cours, l’information y est publiée. Vérifiez ensuite si les plaintes viennent de tous les joueurs ou d’un groupe : un seul fournisseur d’accès concerné oriente vers un problème de route, pas de serveur.

Les ralentissements arrivent à heure fixe. Cherchez une tâche programmée, une sauvegarde automatique ou un redémarrage planifié — voir Programmer des tâches automatiques. Décalez-la hors des heures de pointe.

Le serveur s’arrête seul sans erreur claire. Relisez la console juste avant l’arrêt (Console et logs). Un arrêt net sans message est typiquement un dépassement de mémoire ; une erreur répétée juste avant désigne la ressource fautive.

Seuls les nouveaux joueurs se plaignent. Ils téléchargent votre contenu personnalisé à la première connexion. Réduisez le volume streamé, ou prévenez-les que la première entrée est longue.

Vous ne trouvez pas. Ouvrez un ticket de support en décrivant ce que vous avez mesuré : les trois ressources les plus coûteuses dans resmon, le nombre de joueurs au moment du problème, et les lignes de console autour de l’incident. Un ticket avec des mesures se traite beaucoup plus vite qu’un ticket qui dit « ça lag ».