How to Optimize Your FiveM Server Performance: Complete 2026 Guide

If your FiveM server suffers from lag or high server timing, the cause is usually a mix of hardware limits, unoptimised scripts and slow database queries. This guide walks through each area so you can keep the server stable even with a full slot count and heavy roleplay scripts.

It covers hardware, the most important server.cfg settings, script tuning and database work, with realistic targets at the end.

Why optimisation matters

Player retention

Performance has a direct effect on whether players stay:

• Players leave servers that lag consistently
• Poor performance leads to negative reviews on server lists
• A well-tuned server supports more players on the same hardware

1. Hardware (2026 baseline)

Minimum for around 32 players

CPU: Intel i5-11400 / AMD Ryzen 5 5600X
     (6 cores, 12 threads, 3.5+ GHz base clock)
RAM: 16GB DDR4 3200MHz
Storage: 250GB NVMe SSD Gen 3
Network: 100 Mbps symmetric (upload = download)
OS: Ubuntu 22.04 LTS / Windows Server 2022

Recommended for higher player counts

CPU: AMD Ryzen 7 7800X3D / Intel i7-13700K
     (single-thread optimised, 4.5+ GHz boost)
RAM: 64GB DDR5 6000 CL30
Storage: 1TB NVMe Gen 4 SSD
Network: 1 Gbps dedicated connection
OS: Ubuntu 22.04 LTS

Why these specs

CPU - single-thread performance first:

• FiveM is largely single-threaded
• Clock speed matters more than core count
• AMD X3D cache and recent Intel parts both perform well here

RAM - avoid swapping:

• Heavy script loads use a large base amount of memory
• Map streaming adds to that
• Faster memory gives a small but real gain

Storage - fast SSDs reduce load times:

• NVMe drives cut map streaming and connect times
• Database queries benefit from low latency
• Restarts complete faster

2. server.cfg settings

Your server.cfg controls core behaviour. A sensible starting point:

# ====================================
# ESSENTIAL PERFORMANCE SETTINGS
# ====================================

# OneSync - required for 32+ slots
onesync on

# Player slots (match your hardware)
sv_maxclients 64

# Network bandwidth per client
sv_maxrate 65000
sv_minrate 25000

# Connection quality
sv_packetLoss 0.05
sv_timeout 60

# Database
set mysql_connection_string "mysql://user:password@localhost/database?charset=utf8mb4&maxConnections=10"
set mysql_slow_query_warning 100

Key settings

onesync on:

• Enables 32+ player support
• Improves entity synchronisation
• Required by modern frameworks

sv_maxrate:

• Controls bandwidth per player
• Too low hurts sync quality, too high wastes bandwidth
• A value in the 50,000 to 70,000 range works for most servers

3. Script optimisation

Find the heavy resources

Use the built-in resmon command in the server console:

resmon 1

What to watch for:

• Resources with a high idle time
• Database queries that take too long, usually a missing index
• Client scripts with excessive draw calls

Common performance drains

Checklist

• Use oxmysql for all database operations
• Remove unused resources from server.cfg
• Keep the total resource count lean
• Prefer well-maintained, optimised frameworks
• Load database data lazily where possible
• Clean up spawned entities
• Avoid very short loop intervals where they are not needed
• Cache frequently accessed data in Lua tables

4. Database optimisation

The database is a frequent bottleneck. A few changes make a large difference.

Add indexes to frequently queried columns

-- Check current indexes
SHOW INDEX FROM users;

-- Add indexes for common queries
ALTER TABLE users ADD INDEX idx_identifier (identifier);
ALTER TABLE users ADD INDEX idx_license (license);
ALTER TABLE owned_vehicles ADD INDEX idx_owner (owner);
ALTER TABLE owned_vehicles ADD INDEX idx_plate (plate);

-- Confirm the query uses the index
EXPLAIN SELECT * FROM users WHERE identifier = 'steam:xxxxx';

Use connection pooling

set mysql_connection_string "mysql://user:pass@localhost/db?charset=utf8mb4&maxConnections=10"

Pooling reuses connections instead of opening a new one per query, which reduces overhead and avoids connection-limit errors.

Cache data that does not change

Do not query the database for static data on every call:

-- Avoid: a query on every call
local vehicleName = MySQL.Sync.fetchScalar('SELECT name FROM vehicles WHERE model = ?', {model})

-- Prefer: a cached lookup table
local VehicleNames = {
    ["adder"] = "Truffade Adder",
    ["t20"] = "Progen T20",
    ["turismor"] = "Grotti Turismo R"
}
local vehicleName = VehicleNames[model]

5. Network and DDoS protection

Protect the server from attacks with one of the common options:

6. Asset optimisation

Textures

Uncompressed textures waste VRAM. Convert them to DXT format, keep file sizes reasonable, and use DXT1 for opaque textures, reserving DXT5 for cases that need transparency.

Audio

# Resample audio to game quality
ffmpeg -i input.mp3 -ar 48000 -ac 1 -b:a 128k output.mp3

# -ar 48000   48kHz sample rate
# -ac 1       mono
# -b:a 128k   128 kbps

48kHz mono is enough for almost all game audio.

7. Targets

Before and after

Final checklist

Hardware

• CPU with strong single-thread performance
• Enough RAM for your script load
• NVMe SSD
• Symmetric internet connection

Software

• OneSync enabled
• oxmysql installed and configured
• Current FXServer artifact
• A stable server OS

Scripts

• All resources within a healthy idle time
• No legacy synchronous MySQL scripts
• Inactive resources removed
• Lean total resource count

Testing

• Stable tick time at peak load
• Stress tested above your normal player count
• No memory growth over a long session
• Positive player feedback

Conclusion

Working through hardware, server.cfg, scripts and the database gives you a server that stays smooth at full slots and has room to grow. Treat optimisation as an ongoing habit: monitor regularly, update resources, and test changes on a staging server before going live.