Optimizar servidor FiveM: cómo mejorar el rendimiento y el tickrate

Entra al servidor como jugador y abre la consola con F8. Escribe el comando del monitor de resources:

resmon 1

Esto abre la ventana del Resource Monitor en modo verbose. Las columnas que importan:

• CPU ms — tiempo gastado en el main thread por tick. La suma de todas las filas es el presupuesto total
• Memory — RAM consumida por el resource (problema menos frecuente)
• Streaming — assets descargados por el resource (relevante para mapas)

Anota los 5 resources con mayor CPU ms. Toma una captura para comparar después.

En la consola del servidor (SSH o ventana del FXServer), ejecuta el comando que muestra el tick actual:

status

Verás líneas como Server thread hitch warning: frame time of 28ms. Un frame time por encima de 16.6ms significa que el servidor está perdiendo ticks. Anota el valor promedio durante 5 minutos de juego normal.

Abre txAdmin (puerto por defecto 40120) y ve a “Performance Chart”. Ese gráfico muestra el histórico de tick rate de los últimos 60 minutos. Si ves caídas regulares en horario pico, el problema es de carga, no un bug puntual.

Abre tu server.cfg y localiza las líneas de OneSync. La configuración recomendada para servidores modernos:

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

La flag onesync_distanceCullVehicles quita vehículos detenidos lejos de los jugadores, reduciendo drásticamente la carga de sincronización. enforceGameBuild fija la versión del juego para evitar bugs introducidos por updates de Rockstar.

Si estás corriendo OneSync legacy y quieres migrar a infinity, cambia la línea y prueba tus recursos:

set onesync infinity

Reinicia el servidor y prueba cada script crítico (combate, inventario, garaje). Recursos que dependían de IDs de network locales pueden romperse: la API de infinity usa state bags y routing buckets en su lugar.

Vuelve al resmon y abre los 3 resources con mayor CPU ms. Busca en el código patrones problemáticos. El más común es un loop sin Wait apropiado:

-- MAL: corre cada frame, quema CPU
CreateThread(function()
  while true do
    local player = PlayerPedId()
    -- lógica aquí
    Wait(0)
  end
end)

Wait(0) significa “correr cada frame”. Si la verificación no necesita ser tan frecuente, súbelo a Wait(500) o Wait(1000). Diferencia práctica: un loop con Wait(0) corre 60 veces por segundo; con Wait(1000) corre 1 vez. Para checks de proximidad, status de UI o polling de inventario, 500-1000ms es suficiente.

Busca queries SQL síncronas en hot paths (eventos llamados frecuentemente). Reemplázalas por asíncronas:

-- MAL: bloquea el thread
local result = MySQL.Sync.fetchAll("SELECT * FROM users WHERE id = ?", {id})

-- BIEN: callback asíncrono
MySQL.Async.fetchAll("SELECT * FROM users WHERE id = ?", {id}, function(result)
  -- procesa aquí
end)

Las queries síncronas bloquean el main thread entero mientras la base de datos responde: aunque tarden solo 5ms, son 5ms perdidos en cada llamada.

Los eventos client→server disparados a alta frecuencia son uno de los mayores ofensores. Busca TriggerServerEvent dentro de loops de jugador y añade throttling:

-- Antes
CreateThread(function()
  while true do
    TriggerServerEvent("updatePlayerPosition", GetEntityCoords(PlayerPedId()))
    Wait(100)  -- 10 eventos por segundo, por jugador
  end
end)

-- Después
CreateThread(function()
  while true do
    TriggerServerEvent("updatePlayerPosition", GetEntityCoords(PlayerPedId()))
    Wait(2000)  -- 1 evento cada 2s, suficiente para la mayoría de los casos
  end
end)

Con 50 jugadores, esa es la diferencia entre 500 eventos/segundo y 25 eventos/segundo en el servidor.

Organiza tu carpeta stream/ en subdirectorios por categoría: el FXServer indexa más rápido:

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

Carpetas planas con 5000+ archivos en el mismo directorio hacen que el servidor tarde 10-30 segundos más en iniciar.

Activa el cache de assets en el server.cfg:

sv_assetCacheEnabled true

Esto permite que los clientes mantengan assets en cache entre sesiones, reduciendo descargas repetidas: menos presión de I/O y red cuando los jugadores se reconectan.

Identifica mapas duplicados o conflictivos. Usa el comando en la consola del servidor para listar resources con assets:

list

Busca dos resources streameando el mismo ymap (por ejemplo, dos MLOs del mismo edificio). Un conflicto de streaming causa flickering y a veces crash. Desactiva el duplicado.

Compara el resmon antes/después con el servidor lleno. Cada resource que optimizaste debería haber caído al menos un 30%. La suma total de los resources idealmente por debajo de 12ms.

En txAdmin, observa el Performance Chart durante 30 minutos en horario pico. El tick rate debería mantenerse a 60 Hz con un máximo de 1-2 dips cortos. Frame time promedio por debajo de 16.6ms.

Pide feedback a 3-5 jugadores activos. Pregunta específicamente por el lag de input en combate y la sincronización de vehículos. La métrica numérica no captura la percepción: el jugador siente un stutter de 8ms que el resmon no resalta.