How to speed up a FiveM server: resmon, the profiler and common mistakes

When a FiveM server “lags”, the first reaction is often to buy a bigger plan. Usually that doesn't help: the delay is typically caused by one or a few scripts that needlessly load the server's main thread or the players' clients. This article shows how to find where the problem is using the tools FiveM and txAdmin provide, and which script mistakes come up most often.

Why it lags: server vs. client

The server side of FiveM (FXServer) handles most script work on its main thread. When a tick takes longer than it should, the server falls behind and the console shows a hitch warning (hitch warning). Players notice delayed actions, desync or “teleporting” vehicles — all of them at once. Because it is one thread, more CPU cores won’t help; what matters is single-core performance and, above all, how much work the scripts put on that thread.

The second type of problem is client-side: low FPS or stutter for players while the server itself runs fine. This is usually caused by client scripts with expensive loops or heavy streamed assets. Before optimising anything, find out which type you have — they have different causes and different tools.

resmon: the client resource monitor

The quickest first step is the built-in resource monitor. In game, open the console with F8 and type:

resmon 1

A table appears showing CPU time in milliseconds and memory for each resource on your client. Note: resmon shows the client side, not the server. Look mainly for resources with high time even when nothing is happening — you are standing still with no menu open. As a rough community rule of thumb, an idle script should sit close to zero, and values that stay around tenths of a millisecond or higher deserve a closer look. It is not a precise threshold; mostly compare scripts against each other.

The server-side profiler

For the server side, FiveM has a built-in profiler. In the server console (in txAdmin or the panel) you record a number of frames; the official documentation suggests starting with 500:

profiler record 500
profiler status
profiler view
profiler saveJSON capture.json

profiler status shows whether recording is still running. On the server, profiler view prints a link you open manually in Chrome, and saveJSON saves the capture to a file you can later load in Chrome’s developer tools (Performance tab). The timeline shows which resources and functions take time in each tick. Record while the problem is actually happening — ideally with a full server. The same commands also work in the client F8 console. Details are in the profiler documentation.

Performance charts in txAdmin

The txAdmin dashboard shows server performance and player count over time. This lets you see whether problems appear only at peak times, grow steadily since the last restart, or started after adding a specific script. Keep notes on when you changed what — without them the cause is much harder to find.

The most common script mistakes

• Loops with Wait(0) — they run every frame. On the client they are sometimes necessary (drawing markers, controls), but they are often used where checking every few hundred milliseconds would do. A good pattern: wait longer while the player is far from a zone, and switch to Wait(0) only when they are close.
• Polling instead of events — a script keeps checking state in a loop (job, money, vehicle) instead of reacting to the event the framework fires when it changes.
• Database queries in loops — a query per player in a loop or on every tick. Load data once, keep it in memory and write in batches.
• Missing indexes — tables searched by player identifier or owner without an index on that column. Such queries slow down as the row count grows.
• Too many resources and duplicates — two scripts doing the same thing, old versions next to new ones, unused resources that still start.
• Unoptimised MLOs and streamed assets — large textures and models mainly load players’ clients (memory, loading, FPS), not the server CPU.

-- Instead of a constant Wait(0), wait based on distance
CreateThread(function()
    while true do
        local sleep = 1000
        local dist = #(GetEntityCoords(PlayerPedId()) - zoneCoords)
        if dist < 10.0 then
            sleep = 0
            -- draw marker, check key press
        end
        Wait(sleep)
    end
end)

Database tuning basics

The oxmysql library can warn about slow queries. You set the threshold in milliseconds with the mysql_slow_query_warning convar, and you can temporarily enable query logging for selected resources only with mysql_debug:

set mysql_slow_query_warning 150
set mysql_debug ["suspect_script"]

Once you know which query is slow, check whether the columns in the WHERE clause are indexed, whether the query loads whole tables needlessly (SELECT * on large tables) and whether it is called more often than necessary. Prune or archive old records (logs, transaction history) regularly. Turn debug logging off when you are done — it floods the console on its own.

Regular restarts and up-to-date artifacts

Many servers schedule restarts once or several times a day; txAdmin can set these up with warnings for players. A restart frees memory that poorly written scripts gradually hold on to, but it is a workaround, not a fix — if performance drops quickly between restarts, find the cause with the profiler. Also keep artifacts up to date: newer builds bring fixes, just test your scripts after updating. How to change the version in our panel is covered in the FiveM artifacts guide. Take a backup before bigger changes — with us you create it yourself in the panel (panel basics).

Hardware plays its part: because single-core performance decides, our FiveM plans use AMD Ryzen 9 5900X CPUs and NVMe SSDs, with the MySQL database on the same machine. A vCore here is a cap on a shared physical processor — so more vCores alone won’t speed up the main thread. What else to check with hosting is covered in How to choose FiveM hosting, and the framework choice in ESX vs QBCore vs Qbox.

Summary

First find out whether the server, the client or the database is suffering. On the client use resmon 1, on the server profiler record and profiler view, watch performance over time in txAdmin, and enable oxmysql slow query warnings for the database. Most often the fix is to repair Wait(0) loops, replace polling with events, move database queries out of loops, add indexes and remove unnecessary resources. Regular restarts and current artifacts are a good baseline, but they don’t replace fixing the actual cause.