Performance Testing

Test your server under load to identify performance issues before they affect players.

Load Testing

Synthetic Players (Peds)

Spawning synthetic peds simulates player load on the server’s entity management system. This helps test sync bandwidth and client-side performance in crowded areas.

RegisterCommand('testload:peds', function(source, args)
    local count = tonumber(args[1]) or 50
    local model = `a_m_y_skater_01`
    local peds = {}
 
    RequestModel(model)
    while not HasModelLoaded(model) do Wait(0) end
 
    local playerPed = PlayerPedId()
    local coords = GetEntityCoords(playerPed)
 
    for i = 1, count do
        -- Random offset within 20 units
        local x = coords.x + math.random(-20, 20)
        local y = coords.y + math.random(-20, 20)
        local ped = CreatePed(4, model, x, y, coords.z, 0.0, true, true)
        
        -- Make them wander to simulate activity
        TaskWanderStandard(ped, 10.0, 10)
        table.insert(peds, ped)
    end
    
    print(('Spawned %d test peds'):format(count))
end, true)

Synthetic Vehicles

Test vehicle synchronization and physics load. Large amounts of vehicles can heavily impact server-side physics calculations and client FPS.

RegisterCommand('testload:vehicles', function(source, args)
    local count = tonumber(args[1]) or 30
    local model = `blista`
    
    RequestModel(model)
    while not HasModelLoaded(model) do Wait(0) end
 
    local playerPed = PlayerPedId()
    local coords = GetEntityCoords(playerPed)
 
    for i = 1, count do
        local x = coords.x + math.random(-30, 30)
        local y = coords.y + math.random(-30, 30)
        CreateVehicle(model, x, y, coords.z, 0.0, true, true)
    end
end, true)

Monitoring Tools

1. Resource Monitor (Resmon)

Press Ctrl + Alt + R (or type resmon 1 in F8) to open the Resource Monitor.

• CPU msec: Time spent executing code per frame. Target < 0.5ms for idle resources.
• Memory: RAM usage. High usage might indicate memory leaks.
• Streaming: Check for large assets causing bandwidth spikes.

2. Profiler

Use the built-in profiler to find bottlenecks in specific functions.

1. Open console (F8).
2. Type profiler record 500 (records 500 frames).
3. Type profiler view to open the analysis in Chrome.
4. Look for “long frames” and identify which resource script is taking the most time.

3. ETW (Event Tracing for Windows)

For deep server-side analysis on Windows host machines, use ETW traces to see system-level calls (disk I/O, network stack).

Test Scenarios

Scenario A: Mass Event

Simulate a car meet or robbery.

1. Spawn 50 vehicles in one location.
2. Spawn 50 peds.
3. Monitor client FPS and server tick rate.
4. Success metric: Server tick time stays below 50ms (20 TPS).

Scenario B: Database Stress

Spam database save events to check for I/O blocking.

-- CAUTION: Run only on dev DB
RegisterCommand('test:dbsave', function()
    print("Starting DB stress test...")
    for i=1, 100 do
        MySQL.insert('INSERT INTO logs (message) VALUES (?)', {'Test log ' .. i})
    end
    print("DB stress test queued.")
end)

Best Practices

• Isolate Tests: Don’t run load tests on a production database.
• Baseline: Measure performance on an empty server first to know your hardware limits.
• Client Specs: Test with low-end client hardware if possible, as they are the first to suffer from unoptimized assets.
• Cleanup: Always restart the server after heavy load testing to clear residual entities.