FiveM-server lag oplossen: van OneSync tot zware scripts

Niets sloopt een roleplay-avond zo snel als een haperende server: auto's die teleporteren, een inventory die seconden nodig heeft om te openen, NPC's die bevriezen op de stoep. Het goede nieuws is dat FiveM-lag bijna altijd een aanwijsbare oorzaak heeft. Het slechte nieuws: die oorzaak zit zelden waar je hem als eerste zoekt.

Eén onderscheid vooraf scheelt je uren zoekwerk. Lage FPS bij spelers is een client-probleem: zware maps, te veel props, matige pc's. Rubberbanding, trage events en acties die pas na seconden doorkomen zijn meestal server-side — en dat is het deel dat jij als beheerder zelf in de hand hebt.

Meet eerst, gok daarna

De grootste fout die je kunt maken is meteen resources uitzetten omdat iemand in Discord riep dat script X zwaar is. Begin bij de cijfers. txAdmin, het standaardpaneel van FiveM, toont op het dashboard een performancegrafiek: hoe lang je server per tick nodig heeft. Blijft die grafiek netjes in het groen, dan is het serverproces gezond en zit het probleem eerder bij clients of netwerk. Zie je pieken die samenvallen met de klachten van je spelers, dan weet je zeker dat je server-side moet zoeken.

Kijk daarnaast in de serverconsole. FiveM meldt zelf wanneer een tick te lang duurt met zogeheten hitch warnings, inclusief het aantal milliseconden dat de tick kostte. Eén losse hitch tijdens het opstarten is normaal; een console vol hitch warnings tijdens piekuren is een concreet spoor.

Noteer ten slotte wánneer de lag optreedt. Alleen 's avonds met veel spelers online? Dan schaalt iets slecht mee met spelersaantallen — denk aan events die per speler vuren of database-queries die zich opstapelen. Ook merkbaar met vijf man? Dan is één resource of query structureel traag, en dat is eigenlijk goed nieuws: die vind je sneller.

OneSync: meer spelers, meer serverwerk

OneSync verplaatst het synchroniseren van entiteiten — voertuigen, NPC's, objecten — van de clients naar de server. Daardoor kun je ruim boven de klassieke slotlimiet uitkomen en krijgt de server de regie over wat elke speler ziet: entiteiten ver buiten bereik worden geculld en niet meer gesynchroniseerd.

Dat is grotendeels winst, maar besef wat je inruilt. Al dat synchronisatiewerk landt op de processor van je server en groeit mee met elke extra speler. Een server die met dertig man soepel draait, kan met zestig man tegen zijn plafond lopen zonder dat er één script veranderd is. Daarnaast gedragen sommige stokoude scripts uit het pre-OneSync-tijdperk zich vreemd: ze gaan ervan uit dat elke entiteit voor iedereen bestaat, en dat klopt met culling niet meer.

OneSync uitzetten is dus geen serieuze anti-lag-truc, wat sommige forums ook beweren. Wel geldt: hoe hoger je slotaantal, hoe zwaarder single-core-prestaties en netjes geschreven scripts gaan meewegen.

Zware scripts opsporen

Verreweg de meeste server-side lag komt uit slecht geschreven resources. Zo vind je de boosdoeners:

• resmon: open in de F8-console het commando resmon. Je ziet per resource hoeveel milliseconden die per frame kost. Alles wat structureel hoog scoort terwijl er niets gebeurt, verdient een kritische blik.
• De profiler: voor de serverkant heeft FiveM een ingebouwde profiler. Met profiler record 500 neem je vijfhonderd ticks op en met profiler view zie je per resource en per functie waar de tijd blijft hangen.
• De halveringsmethode: geen zin in profilers? Zet op een testserver de helft van je resources uit en kijk of de lag verdwijnt. Herhaal dat met de verdachte helft. In een paar rondes heb je de dader te pakken.

Let bij resmon wel op wat je meet: op de client zie je vooral wat een resource jouw eigen game kost, terwijl de profiler op de server laat zien wat het serverproces te verduren krijgt. Een script kan client-side onschuldig ogen en server-side alsnog de tick verstoppen — of andersom. Meet dus aan beide kanten voordat je conclusies trekt.

Klassieke zondaars: loops die elke frame draaien zonder wachttijd, scripts die continu over álle spelers of entiteiten itereren, en events die bij elke kleine actie naar alle clients worden gestuurd. Ook populaire betaalde scripts zijn hier niet immuun voor — beoordeel op metingen, niet op reputatie of prijs.

Belangrijk om eerlijk te zijn: soms is de oplossing niet leuk. Een geliefd script dat aantoonbaar je tickrate sloopt, moet je updaten, vervangen of laten herschrijven. Er is geen servervariabele die slecht geschreven code compenseert.

De database als stille rem

Bijna elke roleplay-server hangt aan een MySQL-database via een connector als oxmysql. Gaat het openen van inventories of het opslaan van spelers traag terwijl je performancegrafiek groen blijft, zoek het dan hier.

• Trage queries: zet de slow query log van MySQL aan en kijk welke queries erbovenuit steken. Vaak ontbreekt simpelweg een index op een kolom waarop constant gezocht wordt, zoals de speler-identifier.
• Te veel queries: sommige scripts slaan bij elke kleine wijziging het complete karakter of de hele inventory op. Met tien spelers merk je daar niets van, met vijftig wel.
• Afstand: draait je database op een andere locatie dan je gameserver, dan betaal je bij elke query netwerklatentie. Houd ze dicht bij elkaar, het liefst op dezelfde machine of hetzelfde netwerk, en op snelle opslag zoals NVMe.
• Wachtende scripts: sommige oudere scripts wachten blokkerend op een antwoord van de database voordat ze verdergaan. Elke trage query legt dan meteen een stuk van je server stil. Nieuwere connectors en scripts doen dit netter, dus verouderde resources updaten loont dubbel.

Hardware: single-core snelheid wint

Het zware synchronisatie- en scriptwerk van een FiveM-server draait grotendeels op één thread. Een processor met hoge kloksnelheid en sterke single-core-prestaties doet daarom meer voor je tickrate dan een berg extra cores. Geheugen bepaalt vooral hoeveel resources en spelers je kwijt kunt, en snelle opslag scheelt bij je database en laadtijden.

Bij MC-Node draaien FiveM-servers op eigen hardware met NVMe-opslag en DDoS-bescherming in het Previder-datacenter in Hengelo — lage ping voor Nederlandse en Belgische spelers dus. Alle pakketten zijn maandelijks opzegbaar, zodat je klein kunt beginnen en pas opschaalt als je metingen daarom vragen:

Eerlijk is eerlijk: een zwaarder pakket lost slecht geschreven scripts niet op. Maar zit je met een opgeruimde server alsnog structureel tegen je plafond, dan is upgraden de logische stap. Vergelijk de opties in de FiveM-pakketten van MC-Node en schuif een maatje op — door de maandelijkse opzegbaarheid zit je nergens aan vast.

Je stappenplan in het kort

1. Bevestig met de txAdmin-grafiek en hitch warnings dat het probleem echt server-side zit.
2. Draai resmon en de profiler tijdens piekuren, niet om drie uur 's nachts op een lege server.
3. Pak de zwaarste resource aan: updaten, vervangen of herschrijven.
4. Controleer de database op trage queries en ontbrekende indexes.
5. Zijn scripts en database op orde en loop je alsnog vast? Dan pas is hardware het antwoord.

Wie in deze volgorde werkt, lost de meeste lag binnen een avond op — en weet bovendien zeker dat een eventuele upgrade geen duur pleistertje is, maar een gerichte keuze.