FiveM Server Optimization

Reading resmon without guessing

Everything starts in the client console. Press F8, type resmon and you get the resource monitor, which the Cfx.re docs describe as monitoring CPU usage in milliseconds and memory usage for each resource. Two columns matter. The millisecond column is how long that resource spent executing during the last tick, and the memory column is how much it holds. Only the first one causes stutter.

Read it while playing, not while standing in the spawn menu. A marker script costs nothing in an empty field and costs everything in a downtown block with forty registered points in range. Walk your busiest zone, open a menu, drive fast through the city, and watch which rows climb. Resmon is a client tool, so it only sees client scripts: server side cost is a different measurement covered further down.

What counts as an acceptable ms

Cfx.re publishes no official pass or fail number, so ignore anyone who quotes one as gospel. The useful benchmark is arithmetic. At 60 FPS a frame lasts 16.6 milliseconds, and that budget covers the game engine, the renderer and every resource you loaded. A server running forty client scripts that each take 0.3 ms is spending more than 12 ms of the frame on Lua alone, which is why players report lag even though no single script looks alarming in isolation. The number that matters is the total, and the way to lower a total is to fix the three worst offenders.

The Lua patterns that actually cost you

Three patterns account for most of what you will find. A loop running per frame over a full config table, distance measured with natives instead of vector math, and a drawing thread that keeps ticking when there is nothing on screen. Here is the version almost every free marker script ships with.

-- BEFORE: 500 config entries, distance natives, one tight thread
Citizen.CreateThread(function()
    while true do
        Citizen.Wait(0)
        local ped = PlayerPedId()
        local coords = GetEntityCoords(ped)
        for _, v in pairs(Config.Markers) do
            local dist = GetDistanceBetweenCoords(
                coords.x, coords.y, coords.z,
                v.coords.x, v.coords.y, v.coords.z, true)
            if dist < 30.0 then
                DrawMarker(1, v.coords.x, v.coords.y, v.coords.z - 1.0,
                    0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
                    1.5, 1.5, 0.5, 0, 155, 255, 100,
                    false, false, 2, false, nil, nil, false)
            end
        end
    end
end)

Two things are wrong. The whole table is walked sixty times a second even when the nearest point is two kilometres away, and every iteration calls GetDistanceBetweenCoords, which crosses the native boundary. CfxLua has first class vectors, so #(a - b) gives you the same distance in pure Lua. A well known community writeup measured that single substitution taking a marker resource from over 0.4 ms to 0.28 ms, then down to 0.05 ms once the thread was split and the render distance reduced.

-- AFTER: a slow scanner feeds a render thread that idles when empty
-- Config.Markers[i].coords must be a vector3 for #(a - b) to work.
local nearby = {}

Citizen.CreateThread(function()            -- runs twice per second
    while true do
        local coords = GetEntityCoords(PlayerPedId())
        local found = {}
        for _, v in pairs(Config.Markers) do
            local dist = #(coords - v.coords)
            if dist < 15.0 then
                v.dist = dist
                found[#found + 1] = v
            end
        end
        nearby = found
        Citizen.Wait(500)
    end
end)

Citizen.CreateThread(function()            -- renders only what the scanner found
    while true do
        local count = #nearby
        if count == 0 then
            Citizen.Wait(500)              -- nothing on screen, stop burning frames
        else
            for i = 1, count do
                local v = nearby[i]
                DrawMarker(1, v.coords.x, v.coords.y, v.coords.z - 1.0,
                    0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
                    1.5, 1.5, 0.5, 0, 155, 255, 100,
                    false, false, 2, false, nil, nil, false)
            end
            Citizen.Wait(0)
        end
    end
end)

The other half of the same idea is the adaptive sleep. One thread, one variable, and the wait time changes with what the player is doing. This is the pattern to use for a shop prompt, a job point or anything where the interaction only exists inside a small radius. The marker types and sprite IDs you will pass to DrawMarker are catalogued in the FiveM blips and markers reference.

-- One thread, variable sleep: 1 tick per second far away, per frame up close
local SHOP = vector3(25.7, -1347.3, 29.49)

Citizen.CreateThread(function()
    while true do
        local sleep = 1000
        local coords = GetEntityCoords(PlayerPedId())

        if #(coords - SHOP) < 15.0 then
            sleep = 0
            DrawMarker(27, SHOP.x, SHOP.y, SHOP.z - 0.95,
                0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
                0.9, 0.9, 0.9, 0, 155, 255, 120,
                false, false, 2, false, nil, nil, false)

            if #(coords - SHOP) < 1.6 then
                BeginTextCommandDisplayHelp("STRING")
                AddTextComponentSubstringPlayerName("Press ~INPUT_CONTEXT~ to open the shop")
                EndTextCommandDisplayHelp(0, false, true, -1)

                if IsControlJustReleased(0, 38) then   -- E
                    TriggerServerEvent("var:shop:open")
                end
            end
        end

        Citizen.Wait(sleep)
    end
end)

Three rules cover the rest. Cache anything you call more than once per frame, so PlayerPedId() and GetEntityCoords go in a local at the top of the tick, never inside the inner loop. Register text entries and load animation dictionaries once on resource start, not on every frame. And when a script needs to watch many models at once, put them all on one shared scanner thread rather than spawning a thread per registration, which is how Var-Interact handles hash based registrations: squared distance checks, a single configurable scanner interval, and prompts that only arm inside range.

Server hitches and the profiler

Resmon never sees the server. When a server side resource takes too long inside one tick, FXServer prints a thread hitch warning telling you the main thread stalled and for how many milliseconds. The Cfx.re fact sheet is blunt about what that means: a hitch warning indicates that one of your resources is not performing as it should. A handful during startup is normal. Repeated hitches with players connected are exactly what your community experiences as rubber banding and delayed events.

The profiler turns the warning into a file and a line number. Run the capture while the console is producing warnings, then open it. Chrome is required for the viewer. Hovering a spike in the CPU graph reveals the resource tick, the millisecond cost and the source location responsible.

profiler record 500          # capture 500 frames
profiler status              # confirm it is recording
profiler view                # open the timeline in Chrome
profiler saveJSON hitch.json # or keep it for later

While you are on the server, check what build you are running. Cfx.re promotes vetted builds to the Recommended channel and publishes master branch builds to Latest as soon as CI passes, and an old artifact carries scheduler bugs that were fixed months ago. Update to the newest Recommended build, restart, and re-measure before blaming a script. If you have not set the server up yet, the full installation walkthrough covers artifacts, txAdmin and server.cfg from zero.

OneSync, culling and routing buckets

OneSync decides how much work the server does before any of your Lua runs. Legacy mode caps out at 48 slots. Infinity raises the object ID pool from 8192 to 65535 and culls entities outside a focus zone of roughly 424 units around each player, which is what makes counts above 64 possible at all. The convars below are the ones that matter, and the two marked as startup only cannot be changed with a live restart of the resource.

# 1 to 2048. Values from 32 need onesync on or legacy, above 64 needs onesync on.
sv_maxClients 64
onesync on

# Startup only. Leave both true unless you know exactly why not.
set onesync_enableInfinity true
set onesync_population true

# Sync throttling: drop far entities, refresh near ones more often.
set onesync_distanceCulling true
set onesync_radiusFrequency true

Routing buckets are the underused half. A bucket is a separate synchronisation namespace: players inside one only see entities and players in the same bucket. Put a heist instance, a race or a test drive in its own bucket and the server stops broadcasting that activity to the other 60 players. Turning off ambient population inside the bucket removes the traffic and pedestrians nobody in an interior needs.

-- server side: isolate a crew, no ambient population, strict entity lockdown
local BUCKET = 42

for _, playerId in ipairs(crew) do
    SetPlayerRoutingBucket(playerId, BUCKET)
end

SetRoutingBucketPopulationEnabled(BUCKET, false)
SetRoutingBucketEntityLockdownMode(BUCKET, "strict")

Lockdown mode accepts strict (clients create nothing), relaxed (script owned entities blocked) and inactive (unrestricted). On a roleplay server, relaxed on the default bucket also removes an entire category of entity spawning exploits.

Streaming, assets and the client side of lag

When players report stutter that resmon cannot explain, it is usually the streamer, not Lua. Type strdbg in the F8 console to see what the GTA streamer is loading in real time. Textures are the usual culprit: a single vehicle shipped with 4K uncompressed YTD files can weigh more than thirty properly compressed ones, and every player pays that cost in load time and in memory. Compress vehicle and clothing textures, delete the duplicate props that three different MLO packs all stream, and split one enormous stream folder into per resource folders so you can disable them one at a time while testing. The add-on vehicle pipeline and its meta files are covered in the guide on adding cars to FiveM.

Two more client side wins. Run netgraph to separate a rendering problem from a network problem: if ping is stable and bytes in are low while frames still drop, the fault is local. And audit your loading screen and NUI resources, because a browser page left running behind the game costs frames for the entire session, not just during the load.

Database: where server ticks go to die

Most hitch warnings on a mature server trace back to the database. The classic shape is a save loop that fires one query per online player inside a single tick, every sixty seconds. With 60 players that is 60 round trips queued at once, and the main thread waits.

-- BEFORE: one query per player, every minute, all in the same tick
CreateThread(function()
    while true do
        Wait(60000)
        for _, playerId in ipairs(GetPlayers()) do
            local xPlayer = ESX.GetPlayerFromId(playerId)
            MySQL.update.await("UPDATE users SET money = ? WHERE identifier = ?", {
                xPlayer.getMoney(), xPlayer.identifier
            })
        end
    end
end)

oxmysql exposes MySQL.prepare, which executes a frequently repeated statement faster and accepts multiple parameter sets in a single call. Build the parameter list first, send it once, and stretch the interval: a money save every five minutes plus a save on disconnect loses nothing a player will notice.

-- AFTER: one prepared statement, one round trip, a saner interval
CreateThread(function()
    while true do
        Wait(300000)
        local params = {}
        for _, playerId in ipairs(GetPlayers()) do
            local xPlayer = ESX.GetPlayerFromId(playerId)
            params[#params + 1] = { xPlayer.getMoney(), xPlayer.identifier }
        end
        if #params > 0 then
            MySQL.prepare("UPDATE users SET money = ? WHERE identifier = ?", params)
        end
    end
end)

Two adjacent fixes. Prepare only accepts positional ? placeholders, so named and column placeholders will throw. And index the columns you filter on: an inventory table without an index on the identifier column turns every lookup into a full table scan, which is invisible with 200 rows and fatal with 200,000.

A diagnosis that actually converges

Change one thing at a time and measure between changes, otherwise you will never know what helped. The order below works because it separates the two halves of the problem before touching any code.

The uncomfortable conclusion of most audits is that the cheapest performance win is deleting a script nobody uses. A server with 25 well written resources beats a server with 90 resources of which 60 are free scripts installed once and never removed.

Related: How to make a FiveM server · Best FiveM scripts 2026