How to optimize FiveM server performance and hold 60 Hz tickrate

Join the server as a player and open the console with F8. Type the resource monitor command:

resmon 1

This opens the Resource Monitor in verbose mode. The columns that matter:

• CPU ms — time spent on the main thread per tick. The sum of all rows is your total budget
• Memory — RAM consumed by the resource (rarely the problem)
• Streaming — assets streamed by the resource (relevant for map packs)

Note the top 5 resources by CPU ms. Take a screenshot for comparison later.

In the server console (SSH or FXServer window), run the command that shows the current tick:

status

You’ll see lines like Server thread hitch warning: frame time of 28ms. Frame time above 16.6ms means the server is dropping ticks. Note the average value over 5 minutes of normal gameplay.

Open txAdmin (default port 40120) and go to “Performance Chart”. This chart shows tick rate history for the last 60 minutes. If you see regular drops during peak hours, the problem is load — not a one-off bug.

Open your server.cfg and find the OneSync lines. Recommended config for modern servers:

set onesync on
set onesync_population true
set onesync_distanceCullVehicles true
sv_enforceGameBuild 2944
sv_maxclients 64

The onesync_distanceCullVehicles flag removes parked vehicles far from players — drastically cuts sync load. enforceGameBuild pins the game version to avoid bugs introduced by Rockstar updates.

If you’re running OneSync legacy and want to migrate to infinity, swap the line and test your resources:

set onesync infinity

Restart the server and test every critical script (combat, inventory, garage). Resources that relied on local network IDs may break — the infinity API uses state bags and routing buckets instead.

Go back to resmon and open the top 3 resources by CPU ms. Look through the code for problematic patterns. The most common one is a loop without proper Wait:

-- BAD: runs every frame, burns CPU
CreateThread(function()
  while true do
    local player = PlayerPedId()
    -- logic here
    Wait(0)
  end
end)

Wait(0) means “run every frame”. If the check doesn’t need to be that frequent, raise it to Wait(500) or Wait(1000). Practical difference: a loop with Wait(0) runs 60 times per second; with Wait(1000) it runs once. For proximity checks, UI status or inventory polling, 500-1000ms is plenty.

Look for synchronous SQL queries in hot paths (events called frequently). Replace them with async:

-- BAD: blocks the thread
local result = MySQL.Sync.fetchAll("SELECT * FROM users WHERE id = ?", {id})

-- GOOD: async callback
MySQL.Async.fetchAll("SELECT * FROM users WHERE id = ?", {id}, function(result)
  -- process here
end)

Sync queries block the entire main thread while the database responds — even if it only takes 5ms, that’s 5ms lost on every call.

Client→server events fired at high frequency are one of the worst offenders. Look for TriggerServerEvent inside player loops and add throttling:

-- Before
CreateThread(function()
  while true do
    TriggerServerEvent("updatePlayerPosition", GetEntityCoords(PlayerPedId()))
    Wait(100)  -- 10 events per second, per player
  end
end)

-- After
CreateThread(function()
  while true do
    TriggerServerEvent("updatePlayerPosition", GetEntityCoords(PlayerPedId()))
    Wait(2000)  -- 1 event every 2s — enough for most cases
  end
end)

With 50 players, that’s the difference between 500 events/second and 25 events/second on the server.

Organize your stream/ folder into subdirectories by category — FXServer indexes them faster:

resources/[maps]/my-map/
├── fxmanifest.lua
├── stream/
│   ├── ymap/
│   ├── ytd/
│   └── ydr/

Flat folders with 5000+ files in the same directory add 10-30 extra seconds to server startup.

Enable asset cache in server.cfg:

sv_assetCacheEnabled true

This lets clients keep assets cached between sessions, reducing repeat downloads — less I/O and network pressure when players reconnect.

Look for duplicate or conflicting maps. Use the server console command to list resources with assets:

list

Find any two resources streaming the same ymap (e.g. two MLOs of the same building). Streaming conflicts cause flickering and sometimes crashes. Disable the duplicate.

Compare resmon before/after with the server full. Every resource you optimized should be down at least 30%. Total resource sum ideally below 12ms.

In txAdmin, watch the Performance Chart for 30 minutes during peak hours. Tick rate should hold 60 Hz with at most 1-2 short dips. Average frame time below 16.6ms.

Ask 3-5 active players for feedback. Specifically ask about input lag in combat and vehicle sync. Numeric metrics don’t capture perception — players notice 8ms stutter that resmon won’t flag.