Cómo optimizar tu servidor FiveM: rendimiento y FPS

Un servidor de FiveM que va fino se nota en todo: los jugadores no sufren tirones, los eventos masivos no derriten el hilo principal y el hosting aguanta el doble de gente con la misma máquina. Optimizar un servidor FiveM no es magia negra ni consiste en copiar convars de un foro: es medir, encontrar a los culpables reales y corregirlos uno a uno. En esta guía te enseñamos el método completo, del resmon a la base de datos, para que tu servidor rinda como debe.

Mide antes de tocar nada: resmon y txAdmin

La primera regla de la optimización: sin datos, no toques nada. FiveM trae las herramientas de serie.

En el cliente, abre la consola F8 y escribe resmon 1. Verás una tabla con cada recurso, su tiempo de CPU por frame (en milisegundos) y su consumo de memoria. Ordénala por tiempo y deja el juego correr un par de minutos mientras te mueves, conduces y abres menús: los recursos problemáticos suben a lo alto de la lista solos.

En el servidor, txAdmin te da la otra mitad de la foto: la pestaña de rendimiento muestra el tiempo de tick del servidor y su evolución, y te avisa cuando el hilo principal se satura. Para cazar picos puntuales existe el profiler integrado: ejecuta profiler record 500 en la consola del servidor, reproduce el problema y revisa la grabación con profiler view.

Apunta los cinco recursos que más consumen en cliente y en servidor. Esa es tu lista de trabajo; todo lo demás es ruido.

Y una regla de método antes de empezar a corregir: cambia una sola cosa cada vez y vuelve a medir. Si desactivas cuatro recursos a la vez y el servidor mejora, no sabes cuál era el culpable ni cuáles puedes devolver. Optimizar sin medir entre cambios es la forma más rápida de acabar con un servidor a medio desmontar y sin diagnóstico. Idealmente, haz estas pruebas en un servidor de desarrollo con una copia de tu base de datos, no en producción con jugadores dentro.

Qué significa un script a 0.00 ms y por qué importa

Cuando decimos que un script “va a 0.00 ms” hablamos de su coste por frame en el resmon cuando está en reposo: un recurso bien hecho no consume CPU mientras no está haciendo nada. Puede subir a 0.10 o 0.20 ms cuando el jugador interactúa con él, y eso es normal; lo grave es el script que marca 0.30 ms constantes sin que nadie lo use.

¿Por qué importa tanto? Porque el presupuesto por frame es minúsculo. Para renderizar a 60 FPS, el cliente dispone de unos 16 ms por frame para TODO: motor gráfico, físicas, red y tus scripts. Diez scripts “baratos” a 0.3 ms en reposo son 3 ms de cada frame quemados en nada, casi un 20 % del presupuesto. La suma de pequeños derroches es lo que convierte un servidor en una presentación de diapositivas, no un único script catastrófico.

Los culpables típicos

Loops sin Wait adecuado

El patrón más dañino del ecosistema: hilos que se ejecutan cada frame para tareas que no lo necesitan.

-- MAL: comprueba la distancia 60 veces por segundo
CreateThread(function()
    while true do
        Wait(0)
        local coords = GetEntityCoords(PlayerPedId())
        if #(coords - tienda) < 2.0 then
            mostrarAyuda()
        end
    end
end)

-- BIEN: duerme lejos, despierta cerca
CreateThread(function()
    while true do
        local coords = GetEntityCoords(PlayerPedId())
        local cerca = #(coords - tienda) < 20.0
        Wait(cerca and 100 or 1500)
        if cerca and #(coords - tienda) < 2.0 then
            mostrarAyuda()
        end
    end
end)

Wait(0) solo está justificado cuando el trabajo es realmente por frame (dibujar en pantalla, bloquear controles). Para todo lo demás, intervalos dinámicos. Los recursos modernos van más allá y usan puntos de interés basados en eventos (como los zones de ox_lib) que eliminan el polling por completo.

Eventos espameados

Cada TriggerServerEvent viaja por la red y despierta un handler en el servidor. Scripts que disparan eventos en cada frame de una animación, que sincronizan estado con eventos en bucle o que notifican posición constantemente inundan el hilo principal del servidor. En el profiler se ven como picos de tick asociados a un handler concreto. La solución de diseño: agrupar actualizaciones, usar state bags para estado compartido y validar en el servidor con rate limits para que un cliente malicioso no pueda espamear a voluntad.

Queries a la base de datos que bloquean el tick

El servidor de FiveM ejecuta tus scripts en un solo hilo lógico: una query síncrona que tarda 200 ms son 200 ms en los que nada más ocurre en el servidor. Los síntomas son congelones generalizados al guardar personajes o al abrir inventarios. Las reglas:

• Usa oxmysql, nunca el difunto mysql-async.
• Prefiere las variantes asíncronas o await dentro de hilos, y no llames a la base de datos dentro de loops.
• Agrupa guardados: un save masivo cada pocos minutos es mejor que cien queries individuales por minuto.

OneSync Infinity: configúralo bien

OneSync es el sistema de sincronización del servidor y su modo Infinity (set onesync on) es el estándar actual: cada jugador solo recibe información de las entidades cercanas, con culling automático, lo que permite poblaciones grandes sin fundir la red. Añade set onesync_population true si quieres NPCs y tráfico.

Dos consecuencias prácticas para el rendimiento: primero, los scripts antiguos que asumen que “todos ven todo” (recorrer todos los peds del servidor, por ejemplo) se rompen o rinden fatal con Infinity; asegúrate de usar recursos actualizados. Segundo, la creación de entidades desde el servidor debe usar los natives modernos como CreateVehicleServerSetter, que dejan que OneSync gestione el ownership correctamente.

Streaming de assets y MLOs

Todo lo que metas en streaming (MLOs, vehículos, ropa, peds) lo paga el cliente en memoria, disco y tiempo de carga. Un servidor con 15 GB de assets acumulados castiga los FPS de todos sus jugadores, alarga la primera conexión y multiplica los bugs de colisiones, incluidas las famosas caídas por el mapa.

La dieta es simple de enunciar: elimina packs de los que solo usas una fracción, sustituye MLOs pesados por versiones optimizadas y audita cada mapeado antes de subirlo a producción. En nuestra guía de MLOs para FiveM explicamos cómo evaluar la calidad de un mapeado; como regla rápida, desconfía de cualquier interior que desplome los FPS al acercarse.

Base de datos: oxmysql e índices

Con oxmysql instalado, el siguiente salto de rendimiento está en el propio MySQL/MariaDB. Dos acciones concretas:

• Índices en las columnas de búsqueda. Los frameworks buscan constantemente por identifier, citizenid o license. Si esas columnas no tienen índice, cada búsqueda recorre la tabla entera, y con 50.000 personajes acumulados se nota muchísimo. Un CREATE INDEX en las columnas correctas convierte queries de cientos de milisegundos en menos de uno.
• Vigila las queries lentas. oxmysql puede registrar las queries que superan un umbral; actívalo temporalmente y revisa qué recursos generan las peores. Suelen ser siempre los mismos dos o tres.

Cuándo el problema es el hosting

Si tras limpiar scripts y base de datos el tick del servidor sigue alto con pocos jugadores, mira la máquina. FXServer depende brutalmente del rendimiento por núcleo: ocho cores lentos rinden peor que cuatro rápidos. Los VPS con CPU compartida y vecinos ruidosos producen exactamente los mismos síntomas que un script mal hecho, con la diferencia de que van y vienen según la hora del día. Un disco lento alarga cargas y saves, y la RAM justa provoca swapping. En la guía de hosting para servidores FiveM detallamos qué specs pedir y cómo detectar un hosting saturado antes de contratar.

Los scripts bien hechos marcan la diferencia

Al final, la optimización sostenible no consiste en apagar fuegos sino en no provocarlos: la mayor parte del rendimiento de un servidor se decide al elegir sus recursos. Un script bien construido duerme cuando no se usa, valida en el servidor, agrupa sus queries y marca 0.00 ms en el resmon en reposo. Uno mal hecho te costará horas de diagnóstico cada mes, por gratis que fuera; si trabajas con recursos gratuitos, en la guía de scripts gratis para FiveM explicamos cómo separar el grano de la paja.

Optimizar es un ciclo, no un evento: mide con resmon, corrige al peor culpable, vuelve a medir. Si al auditar tu servidor descubres que los recursos problemáticos son insalvables, en nuestro catálogo encontrarás alternativas optimizadas y probadas en producción en nuestro propio servidor de roleplay, compatibles con QBCore, ESX, Qbox y standalone, con actualizaciones gratis de por vida y soporte 24/7 si necesitas ayuda afinándolas.