Documentation 9.6.24

Réglages et performances

Mesurez sur votre serveur. Joueurs, ressources, captures et index influencent la charge ; aucune garantie de latence nulle.

Observer d’abord#

Comparez les détections au jeu normal avant kick ou ban. Testez téléportations, réapparitions et armes légitimes. Les signaux client ne donnent aucun droit sur l’argent, les armes ou l’administration.

Maîtriser les tâches coûteuses#

Gardez analyses profondes et quarantaine automatique désactivées sans tests. Limitez les captures simultanées. Le bridge ne lit pas la base au repos ; HTTPS et les autres modules consomment toujours des ressources. Mesurez les changements avec le profiler FiveM.

Mesurer une référence reproductible#

Profilez une session représentative avant les changements. Notez joueurs, artifact, versions et activité. Roleplay calme, garages pleins et combats diffèrent. Après un seul réglage, comparez le même scénario. CPU, hitches et requêtes valent mieux qu’un gain FPS promis.

Les commandes enregistrent un échantillon borné. Attendez la fin et identifiez ressource et thread responsables du pic. Tous les hitches ne viennent pas de l’AC. Gardez valeurs et comparaison privées ; une courte mesure ne couvre pas tous les pics.

profiler record 500
profiler status
profiler view

tosunac_doctor

Limiter le coût en conservant les protections#

Testez scans profonds et quarantaine automatique dans un cadre contrôlé. Limitez les captures simultanées et désactivez debug en production. Réduire les intervalles de détection ou de polling multiplie le travail.

Mesurez repos et une lecture séparément. Le pont ne lit pas de SQL jeu au repos, mais HTTPS et autres modules utilisent des ressources.
Paginer les grandes listes ; examiner les refus d’index avec le responsable de base.
Mesurer une capture test avant plusieurs observateurs simultanés.
Si la charge augmente, restaurer le réglage et répéter le scénario avant de modifier autre chose.

Choisir les sanctions selon le contexte#

Observez les contrôles contextuels et testez le jeu normal. Un log n’ordonne pas de bannir tout joueur concerné. Vérifiez personnage, réanimation, téléports, police et armes scriptées. Préférez une intégration ciblée à une exemption permanente.

tosunac_doctor rapporte les valeurs actives risquées sans les modifier. Examinez sanctions fortes, protections coupées, debug et fail-open. Le panel peut remplacer les valeurs locales ; vérifiez les valeurs effectives.

Une exemption peut masquer les plaintes sans résoudre leur cause. Listez exceptions temporaires, dates et scripts. Après vérification, retirez l’exception et répétez le parcours en comparant les logs.

Modifier un réglage et noter motif, relecteur et ancienne valeur.
Comparer répétitions aux actions légitimes et horaires.
Retester après changement de sanction, core ou inventaire.
En cas de faux positif nouveau, restaurer et résoudre la cause avant de durcir.

Comparer une charge identique avant et après#

Notez joueurs, versions artifact, AC, framework et inventaire, ainsi que les opérations du panneau. Mesurez d’abord une session calme sans demande, puis sélection de personnage, garage et combat normal. profiler record 500 produit un échantillon limité ; attendez sa fin indiquée par profiler status.

Dans profiler view, identifiez le resource et le thread des pics CPU. Examinez les longues exécutions répétées et avertissements hitch associés, pas seulement la moyenne. Changez un seul réglage puis répétez à charge comparable. Les problèmes de pointe nécessitent une session représentative ; plusieurs changements empêchent d’attribuer le résultat.

Mesurer séparément le pont de données#

La communication de santé ne signifie pas que le pont lit constamment les joueurs dans la base du jeu au repos. Une seule demande sortante est en cours. Le cycle normal est d’environ dix secondes ; les échecs augmentent l’attente jusqu’à deux minutes. Cela décrit le fonctionnement actuel, pas un réglage de vitesse ou un délai garanti de rafraîchissement.

Consultez tosunac_db_status dans la console. Comparez une page de joueurs au profil de repos. Les listes comportent des pages de 25 entrées et des réponses bornées ; toute la base n’est pas transférée. Pour unsupported_index ou schema_unavailable, faites examiner schéma et index compatibles par un administrateur autorisé plutôt que forcer des requêtes plus larges.

Documenter acceptation et retour arrière#

Définissez des critères propres au serveur : absence de nouveaux hitch persistants, parcours normaux complets et hausses de durée expliquées. Un objectif universel de FPS ignore matériels et autres resources. Un profil plus rapide ne justifie pas des faux positifs.

Notez anciennes et nouvelles valeurs, heure, joueurs et effet. Si la charge augmente, restaurez le seul réglage modifié et répétez. Ne modifiez pas de soldes pour mesurer. Fournissez au support un résumé nettoyé et les alertes du doctor. Observez ensuite une session de production normale afin que les conditions du test ne masquent pas la charge réelle.

Distinguer un pic du travail répété#

Ne modifiez pas sur la seule ligne la plus longue. Examinez resource et thread répétés ainsi que l’action associée. Une préparation unique à la connexion diffère du travail à chaque tick. Si le garage produit un pic initial, comparez les ouvertures suivantes. Un autre resource changé empêche d’attribuer la différence uniquement à AC. Une courte trace ne couvre pas toutes les pointes.

Notez durée, fréquence et action ensemble. De nombreux travaux brefs accumulent du temps ; un long peut coïncider avec hitch. Le profiler serveur ne mesure pas les FPS client. Comparez le blocage client au même intervalle serveur ; latence et assets peuvent demander autre analyse. Demandez de l’aide avec extrait nettoyé et scénario plutôt que raccourcir toutes les périodes sans comprendre.

Mesurer le coût de l’observation#

Surveillance et diagnostic produisent aussi du travail. Longue trace, lectures multiples, preuves et debug permanent ensemble compliquent l’attribution. Limitez les outils, puis comparez avec un seul actif. Actualiser plusieurs onglets ne mesure pas mieux une action ; demandes décalées et résultats anciens peuvent brouiller l’observation. Écriture d’argent n’est pas un outil de charge.

Notez sessions du personnel, écran et nombre de preuves. Comparez session normale, lecture joueur et capture éventuelle séparément. Désactivez ensuite les sorties supplémentaires et observez le fonctionnement normal. Recueillez assez de données pour identifier le travail, pas le maximum. Cela vaut pour votre serveur actuel sans garantie ailleurs. Vérifiez la suppression des options temporaires en clôturant la maintenance.

Tenir un petit relevé quotidien de santé#

À une heure représentative similaire chaque jour, tenez un court relevé ; un profiler ou des captures permanentes sont inutiles. Indiquez version installée, nombre de joueurs, nouvelles erreurs répétées de démarrage et état du pont si pertinent. Si une opération du personnel attend, examinez son état plutôt que multiplier les mêmes lectures. Vérifier un parcours normal et, si nécessaire, une page est un entretien plus limité que parcourir toute l’histoire uniquement pour collecter des données.

Ne réenregistrez pas quotidiennement toute une configuration inchangée. Comparez une nouvelle alerte du doctor au relevé précédent et expliquez sa cause ; il ne la répare pas automatiquement. Réexaminez une exception temporaire avec son responsable à la date prévue sans inventer une expiration automatique. Sans nouveau symptôme, clôturez sur l’état normal observé. Pour un nouveau hitch ou une erreur, mesurez uniquement l’intervalle et l’action concernés. Il s’agit d’une routine d’administration, pas d’une nouvelle tâche automatique ni d’une fonction du panel.

Mesurer les archives séparément des joueurs#

Personnages, véhicules et historique de détections peuvent grossir pendant que les joueurs connectés augmentent. Si l’historique devient dix fois plus grand à population identique, chronométrez première page de logs, page suivante et détail d’un personnage connu séparément. Si l’archive reste stable mais la population augmente, examinez le jeu normal. Ne changez pas les deux variables pour attribuer tout écart à AC. Des résultats temporaires du panel ne signifient pas une purge automatique des tables sources de bans ou détections.

La première requête peut préparer les métadonnées, les suivantes profiter du cache ; relevez séparément les échantillons froids et chauds. Pagination et index limitent un transfert global sans supprimer la croissance du stockage. Mesurez la page suivante dans le même contexte au lieu de recharger la première. Si la durée augmente nettement, faites examiner plans et index sur une copie de test. Supprimer l’historique, renommer des tables ou tout exporter n’est pas une mesure. Décidez avec volume, population et opération mesurée ensemble.

Enregistrer des événements validés sur le serveur#

Modifier une exemption côté client ne crée pas d’exemption générale sur le serveur. Le répit local des menus/intégrations concerne seulement le mouvement et la visibilité; les droits d’argent, d’armes et d’événements restent vérifiés. Réservez les exemptions larges aux resources serveur de confiance.

Vérifier les droits et leur retrait#

ACE, identifiants administrateur et droits du panneau sont vérifiés côté serveur. all ne constitue ni identifiant ni autorisation. allowedIds attend license:..., discord:... ou fivem:... complets issus des identifiants du joueur.

Accordez le minimum nécessaire à un administrateur de test.
Retirez le droit du panneau et réessayez avec ce joueur; la nouvelle interrogation par défaut est d’environ cinq secondes.
Vérifiez aussi les droits indépendants ACE/admins.lua. La télémétrie des joueurs en ligne ne donne aucun droit.
Un joueur normal doit rester refusé; testez les actions sensibles avec des données de test.

ts.AdminMenu.allowedIds = {
    "license:YOUR_EXACT_PLAYER_IDENTIFIER",
    "discord:YOUR_DISCORD_USER_ID"
}
# Examples are placeholders, not grants.

Éviter les analyses inutiles après redémarrage#

Chaque démarrage vérifie les empreintes SHA256 du contenu. Les ressources dont les fichiers et règles sont inchangés réutilisent les résultats authentifiés du KVP serveur au lieu de répéter les analyses coûteuses de signatures et événements. Les changements de fichiers, exceptions ou règles déclenchent une nouvelle analyse. Les empreintes nécessitent encore des lectures ; aucune valeur resmon fixe n’est garantie.

Conservez le cache KVP pendant une mise à jour normale ; les entrées corrompues ou invérifiables sont réanalysées.
Le catalogue initial collecte les noms d’événements littéraux Lua/JS. Les noms dynamiques, fichiers illisibles ou escrow et DLL ne sont pas certifiés entièrement analysés.
L’installation automatique manuelle attend l’analyse de sécurité. Les ressources incomplètes, suspectes, modifiées ou expirées ne sont pas approuvées automatiquement.
Testez la connexion des joueurs, le jeu normal et les actions administrateur sur un serveur de test ; évaluez resmon avec le nombre de joueurs et la charge du framework.