Commencez par mesurer l'échec. Un faible FPS client, un temps de ressource élevé, des saccades du serveur, des attentes de base de données et une perte de réseau sont des problèmes différents. Capturez une base de référence reproductible à un nombre de joueurs représentatif avant de supprimer des ressources ou de copier des convars d'un autre serveur.
Méthode : vérifié le 9 août 2026 à partir du guide du profileur, des commandes de console du client et des commandes de serveur officiels de Cfx.re.
1. Définir le symptôme et la ligne de base
- Les FPS d'un joueur chutent : reproduisez sur ce client et inspectez le moniteur de ressources client.
- Tous les joueurs ont des saccades : enregistrez les avertissements de saccades du serveur, le temps des ressources, la latence de la base de données et la saturation du processeur de l'hôte.
- La connexion est lente : inspectez la taille des ressources diffusées, le comportement de téléchargement et le travail d'initialisation.
- Les actions sont lentes : tracez l'événement et la requête de la base de données plutôt que de blâmer les graphiques.
Enregistrez la version de l'artefact, le nombre de joueurs, les ressources actives, l'itinéraire de test et les horodatages. Ne modifiez qu'une seule variable à la fois.
2. Utilisez correctement resmon et le profileur
Dans une configuration de développement autorisée, ouvrez F8 et utilisez resmon true pour une comparaison rapide côté client. Cfx.re classe resmon comme une commande de développeur ; un client normal peut refuser l'accès. Traitez-le comme un indicateur, pas un verdict : le timing varie en fonction de ce que le joueur fait. Reproduisez la même interaction plusieurs fois. Pour des preuves au niveau du code, effectuez une capture du profileur pendant l'action lente et inspectez la portée ou l'événement coûteux.
Gardez le guide détaillé de resmon pour FiveM ouvert pendant les tests.
3. Corriger le code de la ressource au niveau du goulot d'étranglement
- Remplacez les boucles inconditionnelles par image par un travail événementiel ou un intervalle d'attente justifié.
- Validez les événements réseau sur le serveur et n'envoyez que les données dont le client a besoin.
- Évitez de diffuser de grandes charges utiles lorsqu'un événement ciblé est suffisant.
- Mettez en cache les recherches stables, mais invalidez le cache lorsque l'état sous-jacent change.
- Profilez avant et après ; un code plus court n'est pas automatiquement un code plus rapide.
4. Vérifier le travail de la base de données
Enregistrez les temps de requête lente et les sites d'appel ; supprimez les identifiants et les données des joueurs de tout exemple de requête partagé. Ajoutez des index seulement après avoir confirmé le modèle de requête, et évitez les requêtes répétées à l'intérieur des boucles. Regroupez les écritures lorsque cela préserve l’exactitude des données. Testez les reconnexions, les sauvegardes planifiées et les actions économiques de pointe, car une base de données de staging vide peut masquer la latence de production.
5. Budgétiser les ressources diffusées
Vérifiez les textures surdimensionnées, les modèles dupliqués et les packs de ressources qui diffusent beaucoup plus que ce que le serveur utilise. Testez une connexion propre et un emplacement très fréquenté. Vérifiez les niveaux de détail, la résolution des textures et l'intégrité des fichiers avant de compresser ou de supprimer des ressources. Un téléversement corrompu peut ressembler à un problème de performance.
6. Séparez les limites de l'hôte des limites du script
Surveillez la saturation du CPU par cœur, la pression de la mémoire, la latence du stockage, la perte de paquets et l'emplacement de la base de données. Les charges de travail FiveM peuvent saturer un cœur occupé alors que le CPU total semble encore faible. Comparez les hôtes avec la même version et la même charge ; la RAM et les emplacements annoncés ne prouvent pas à eux seuls la capacité.
7. Déployer et surveiller
- Sauvegardez la ressource, la configuration et les tables de base de données affectées.
- Déployez une correction mesurée en staging.
- Répétez le scénario de référence et comparez les mêmes métriques.
- Déployez pendant une fenêtre contrôlée et surveillez les rapports de blocage, d'erreur et de joueurs.
- Annulez immédiatement si la métrique cible ou le flux de jeu régresse.
L'optimisation n'est complète que lorsque le symptôme mesuré s'améliore sans déplacer la défaillance ailleurs.