Halloween at Nexthosting: 10% off game servers with the code – until November 1
Use resmon, the profiler and a measurement log to find your three biggest bottlenecks, fix them and verify the effect. Hardware comes last.
If you want to improve your FiveM server performance, you don't start with hardware but with measuring: only resmon and the built-in profiler show which resource is really eating time on the tick. Next comes checking server.cfg and OneSync, then cleaning up scripts, database access and streaming assets. A hosting upgrade only pays off once profiling shows real saturation of the single-core clock speed, not before.
In short:
- Server performance depends mainly on profiling and analyzing resource usage, not on hardware.
- Optimizing server.cfg and checking scripts and databases are often more effective than faster hosting.
- A hardware upgrade only makes sense if profiling shows that the single core is heavily loaded.
- Verify performance with measurements in idle and under load, and with profiler screenshots.
- Unused or faulty scripts and large streaming assets are often the main causes of performance problems.
Before you change even a single line of code, you need data. resmon is your first stop: the command resmon true in the client console shows server and client milliseconds per resource, and this is exactly where the usual suspects stand out immediately, as a relevant forum thread on server performance describes. Endless loops without a wait, bloated streaming packs and unthrottled database queries almost always show up at the top of the list.
Here is how to proceed in practice:
While you do this, collect screenshots of resmon in idle and under load, the profiler spike and the txAdmin graph. These three artifacts are your evidence folder for every later decision.
Pro tip: Store the resmon values of each resource in a simple table. Compare again after every content update, because a freshly installed vehicle pack can wipe out all of your progress.
Many performance problems are not in the code but in a poorly ordered server.cfg. The load order determines whether dependencies are available at the right time at all.
ox_lib, then the framework, and all remaining resources only at the end.sv_maxclients about 10 to 20% above your actual peak, not arbitrarily high, because every free slot potentially costs entity budget.Duplicate ensure entries are a classic: they cost load time and obscure which resource is actually active.
The most common performance killer is called Citizen.Wait(0). A loop without a real wait runs on every single tick, whether or not anything is happening, which practical optimization guides also name as the main cause of server lag. The same applies to TriggerClientEvent to all clients (-1) when only a handful of players are actually affected.
The alternative is usually simple: adaptive wait times that lengthen depending on state, or a complete switch to event handlers instead of polling. Instead of five resources that query the same player state every few hundred milliseconds, a single central statebag that distributes changes once is often enough.
This is how the fixing process works in practice:
As a target value: very low milliseconds per resource at idle are inconspicuous, and anything well above that deserves a closer look. This rule of thumb combines well with the resource budget from the FiveM Server Optimization Guide, which names an upper limit of around 150 resources as a rough guideline.
Pro tip: Never fix more than three resources between two measurements. Otherwise you won't know in the end which change actually made a difference.
Database access is an underestimated bottleneck because it often disguises itself as seemingly random delays. A player waits two seconds for their inventory to load, and nobody thinks of SQL first.
oxmysql instead of blocking sync queries, because asynchronous access keeps the tick loop free.identifier, citizenid or plate; this sometimes speeds up lookups dramatically.Long asynchronous waits or blocked events are almost always a symptom of missing indexes, not of a server that is too weak.
Client-side FPS drops rarely have anything to do with the server itself, but with what it streams to each client. MLOs, vehicle packs and textures quickly add up to a download volume that causes long loading times when connecting and noticeable stutter afterward.
An effect that is often underestimated: streaming optimization frequently delivers a bigger improvement than a more expensive hosting plan, because it tackles the actual problem, namely client-side stutter rather than server lag, directly. FiveVault describes exactly this relationship between asset size and FPS drops in detail. Long join times and repeated waves of reconnects are usually the first visible symptom of an overloaded streaming folder.
Once profiling and scripts deliver clean values but the CPU is still maxed out, hardware becomes relevant. This is where the classic wrong purchase happens: many providers advertise more cores, even though FiveM processes the tick mostly on a single core.
The decision rule stays simple: if profiling shows lasting saturation of a single core, an upgrade is justified. If it doesn't, new hardware brings little, as the FiveM Server Optimization Guide also emphasizes.
A one-time fix isn't enough, because server state changes over the course of hours, for example through memory leaks in individual resources. Scheduled restarts, for example two to four times a day depending on player count, are a pragmatic interim solution until the actual cause is found.
Pro tip: For every fix, note the date, resource and the measured value before and after in a shared table. After a few months you'll spot patterns that you would otherwise miss.
Most of the performance problems I see in audits have the same origin: unchecked scripts taken straight from forums, missing indexes and a streaming folder that has grown over months without anyone cleaning it up. The good news: if you consistently fix the three most expensive resources after running resmon, you usually resolve the bulk of complaints, without any new hardware. Nexthosting makes sense where profiling actually shows single-core saturation and reliable DDoS protection is also needed, not as the first reflex at every stutter.
— Erik
If your profiling shows that the server is genuinely hitting the single-core limit and not held back by a sloppy script, it's worth a look at the infrastructure itself. Nexthosting offers FiveM hosting with NVMe storage, DDoS protection and plans built for single-core performance rather than raw core count, exactly the factor that makes the difference with FiveM. Instead of switching at every stutter, follow the order from this article: first resmon and the profiler, then server.cfg and OneSync, and only after that the hardware. If you really need more performance after the audit, you'll find the right configurations on the Nexthosting FiveM hosting page and can check directly which plan fits your player count.
For more in-depth measurement guides, the forum thread on server performance is worth reading, as is the official FiveM site for references on convars and artifacts. If you are looking for concrete checklists, the FiveM Server Optimization Guide and FiveVault offer practical tutorials on the profiler and txAdmin.
On the server side, FiveM almost exclusively loads the CPU, in particular the single-core clock speed, while the GPU load falls mainly on the client for graphics and streaming assets.
For most mid-sized roleplay servers, 32 GB of RAM is enough as long as streaming assets and database size stay within reason; with very large asset packs or a high player count, more may be needed.
Measure first with resmon and the profiler, fix the three most expensive resources, and then check server.cfg and OneSync before you even think about a hardware upgrade.
RAM demand depends less on the slot count than on the volume of streaming assets and the database size; a server with few players but a large asset folder can still use a lot of memory.