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 : révisé le 9 août 2026 par rapport au Cfx.re officiel guide du profileur, commandes de la console client et commandes du serveur.
1. Définir le symptôme et la ligne de base
- Le FPS d'un joueur diminue : 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
Ouvrez F8 et utilisez resmon 1 pour une comparaison rapide côté client. Considérez-le comme un indicateur, pas un verdict : le timing varie en fonction de ce que fait le joueur. 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 détail Guide resmon FiveM ouvrir pendant les tests.
3. Corriger le code de la ressource au niveau du goulot d'étranglement
- Remplacer les boucles inconditionnelles par image par un travail événementiel ou un intervalle d'attente justifié.
- Valider les événements réseau sur le serveur et n'envoyer que les données dont le client a besoin.
- Éviter de diffuser de grandes charges utiles lorsqu'un événement ciblé est suffisant.
- Mettre en cache les recherches stables, mais invalider le cache lorsque l'état sous-jacent change.
- Profiler 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
Enregistrer les requêtes lentes avec les paramètres et les sites d'appel. Ajouter des index seulement après avoir confirmé le modèle de requête, et éviter les requêtes répétées à l'intérieur des boucles. Regrouper les écritures lorsque la correction le permet. Tester 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échargement 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.
