Cómo optimizar el rendimiento del servidor FiveM

Empieza por medir el fallo. Un bajo FPS del cliente, un alto tiempo de recursos, tirones del servidor, esperas de la base de datos y pérdida de red son problemas diferentes. Captura una línea de base repetible con un número representativo de jugadores antes de eliminar recursos o copiar convars de otro servidor.

Método: Revisado el 9 de agosto de 2026 según el Cfx.re oficial guía del profiler, comandos de consola del cliente y comandos del servidor.

1. Define el síntoma y la línea de base

• Las FPS de un jugador bajan: reproduce en ese cliente e inspecciona el monitor de recursos del cliente.
• Todos los jugadores tienen tirones: registra avisos de pausas del servidor, tiempos de recursos, latencia de la base de datos y saturación de la CPU del host.
• Unirse es lento: inspecciona el tamaño de los activos transmitidos, el comportamiento de descarga y el trabajo de inicialización.
• Las acciones se retrasan: rastrea el evento y la consulta de la base de datos en lugar de culpar a los gráficos.

Registra la versión del artefacto, el recuento de jugadores, los recursos activos, la ruta de prueba y las marcas de tiempo. Cambia una variable a la vez.

2. Usa resmon y el profiler correctamente

En una configuración de desarrollo permitida, abre F8 y usa resmon true para una comparación rápida del lado del cliente. Cfx.re clasifica resmon como un comando de desarrollador; un cliente normal puede denegar el acceso. Trátalo como un indicador, no como un veredicto: el tiempo varía según lo que esté haciendo el jugador. Reproduce la misma interacción varias veces. Para obtener evidencia a nivel de código, realiza una captura del profiler durante la acción lenta e inspecciona el ámbito o evento costoso.

Mantenga los detalles Guía de resmon de FiveM abiertos mientras prueba.

3. Corrige el código del recurso en el cuello de botella

• Reemplaza los bucles incondicionales por fotograma con trabajo basado en eventos o un intervalo de espera justificado.
• Valida los eventos de red en el servidor y envía solo los datos que el cliente necesita.
• Evita transmitir grandes cargas útiles cuando un evento dirigido sea suficiente.
• Almacena en caché las búsquedas estables, pero invalida la caché cuando cambie el estado subyacente.
• Perfila antes y después; un código más corto no es automáticamente un código más rápido.

4. Comprueba el trabajo de la base de datos

Registra los tiempos de las consultas lentas y los sitios de llamada; oculta las credenciales y los datos de los jugadores en cualquier ejemplo de consulta compartida. Agrega índices solo después de confirmar el patrón de consulta y evita las consultas repetidas dentro de los bucles. Agrupa las escrituras cuando la corrección lo permita. Prueba las reconexiones, los guardados programados y las acciones económicas pico porque una base de datos de prueba vacía puede ocultar la latencia de producción.

5. Presupuesta los activos transmitidos

Audita texturas de gran tamaño, modelos duplicados y paquetes de recursos que transmiten mucho más de lo que usa el servidor. Prueba una conexión desde un cliente limpio y una ubicación concurrida. Verifica los niveles de detalle, la resolución de la textura y la integridad del archivo antes de comprimir o eliminar activos. Una subida de archivos defectuosa puede parecer un problema de rendimiento.

6. Separa los límites del host de los límites del script

Observa la saturación de la CPU por núcleo, la presión de la memoria, la latencia del almacenamiento, la pérdida de paquetes y la ubicación de la base de datos. Las cargas de trabajo de FiveM pueden saturar un núcleo ocupado mientras que el total de la CPU sigue pareciendo bajo. Compara los hosts con la misma compilación y carga; la RAM y las ranuras anunciadas por sí solas no demuestran la capacidad.

7. Implementa y monitorea

1. Haz una copia de seguridad del recurso, la configuración y las tablas de la base de datos afectadas.
2. Implementa una corrección medida en el entorno de prueba.
3. Repite el escenario de referencia y compara las mismas métricas.
4. Lanza durante una ventana controlada y observa los avisos de pausas, errores e informes de los jugadores.
5. Revierte inmediatamente si la métrica objetivo o el flujo de juego retroceden.

La optimización solo se completa cuando el síntoma medido mejora sin mover el fallo a otro lugar.