Begin met het meten van de storing. Lage client FPS, hoge resource tijd, server haperingen, database wachttijden en netwerkverlies zijn verschillende problemen. Leg een herhaalbare basislijn vast bij een representatief aantal spelers voordat je resources verwijdert of convars van een andere server kopieert.
Methode: beoordeeld op 9 augustus 2026 tegen de officiële Cfx.re profiler gids, client console commando's En server commands.
1. Definieer het symptoom en de basislijn
- Eén speler's FPS daalt: reproduceer dit op die client en inspecteer de client resource monitor.
- Alle spelers haperen: registreer serverhaperingswaarschuwingen, bron timing, database latentie en host CPU verzadiging.
- Aanmelden duurt lang: inspecteer gestreamde asset grootte, download gedrag en initialisatie werk.
- Acties haperen: traceer het event en de database query in plaats van de graphics de schuld te geven.
Registreer artifact versie, speler aantal, actieve bronnen, test route en tijdstempels. Verander één variabele tegelijk.
2. Gebruik resmon en de profiler correct
Open F8 en gebruik resmon 1 voor een snelle client-side vergelijking. Beschouw het als een aanwijzing, geen oordeel: timing varieert met wat de speler aan het doen is. Reproduceer dezelfde interactie meerdere keren. Voor bewijs op codeniveau, maak een profiler opname tijdens de trage actie en inspecteer de dure scope of het event.
Houd de gedetailleerde FiveM resmon handleiding open tijdens het testen.
3. Los resourcecode op bij de bottleneck
- Vervang onvoorwaardelijke per-frame lussen door gebeurtenisgestuurde werkzaamheden of een gerechtvaardigd wachtinterval.
- Valideer netwerkgebeurtenissen op de server en stuur alleen de gegevens die de client nodig heeft.
- Vermijd het uitzenden van grote payloads wanneer een gerichte gebeurtenis voldoende is.
- Cache stabiele lookups, maar invalideer de cache wanneer de onderliggende status verandert.
- Profileer voor en na; kortere code is niet automatisch snellere code.
4. Controleer database werkzaamheden
Log trage queries met parameters en aanroeplocaties. Voeg alleen indexen toe nadat het querypatroon is bevestigd, en vermijd herhaalde queries binnen lussen. Batch schrijfacties wanneer de correctheid dit toelaat. Test herverbindingen, geplande opslagacties en piek economische acties, omdat een lege staging database productievertraging kan verbergen.
5. Gebudgetteerde gestreamde assets
Controleer oversized textures, dubbele modellen en resourcepakketten die veel meer streamen dan de server gebruikt. Test een schone join en een drukke locatie. Verifieer detailniveaus, textuurresolutie en bestandsintegriteit voordat assets worden gecomprimeerd of verwijderd. Een defecte upload kan lijken op een prestatieprobleem.
6. Scheid hostlimieten van scriptlimieten
Let op per-core CPU-verzadiging, geheugendruk, opslaglatentie, pakketverlies en databaselocatie. FiveM workloads kunnen één drukke core bottlenecken terwijl de totale CPU nog steeds laag lijkt. Vergelijk hosts met dezelfde build en belasting; RAM en geadverteerde slots alleen bewijzen de capaciteit niet.
7. Uitrollen en monitoren
- Maak een back-up van de resource, configuratie en de getroffen databasetabellen.
- Implementeer één gemeten oplossing op staging.
- Herhaal het basisscenario en vergelijk dezelfde metrieken.
- Breng uit tijdens een gecontroleerd venster en let op hitch, fouten en spelersrapporten.
- Rol onmiddellijk terug als de doelmetriek of de gameplay-flow achteruitgaat.
Optimalisatie is pas voltooid als het gemeten symptoom verbetert zonder de storing elders te verplaatsen.
