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
- El FPS de un jugador baja: reproduce en ese cliente e inspecciona el monitor de recursos del cliente.
- Todos los jugadores tienen tirones: registre advertencias de enganche del servidor, tiempos de recursos, latencia de la base de datos y saturación de la CPU del host.
- Unirse es lento: inspeccione el tamaño de los activos transmitidos, el comportamiento de descarga y el trabajo de inicialización.
- Las acciones se retrasan: rastree el evento y la consulta de la base de datos en lugar de culpar a los gráficos.
Registre la versión del artefacto, el recuento de jugadores, los recursos activos, la ruta de prueba y las marcas de tiempo. Cambie una variable a la vez.
2. Use resmon y el profiler correctamente
Abre F8 y usa resmon 1 para una comparación rápida del lado del cliente. Trátelo como un indicador, no como un veredicto: el tiempo varía según lo que esté haciendo el jugador. Reproduzca la misma interacción varias veces. Para obtener evidencia a nivel de código, tome una captura del profiler durante la acción lenta e inspeccione el alcance o evento costoso.
Mantenga los detalles guía de resmon FiveM abiertos mientras prueba.
3. Corregir el código del recurso en el cuello de botella
- Reemplace los bucles incondicionales por fotograma con trabajo basado en eventos o un intervalo de espera justificado.
- Valide los eventos de red en el servidor y envíe solo los datos que el cliente necesita.
- Evite transmitir grandes cargas útiles cuando un evento dirigido sea suficiente.
- Almacene en caché las búsquedas estables, pero invalide la caché cuando cambie el estado subyacente.
- Perfile antes y después; un código más corto no es automáticamente un código más rápido.
4. Comprobar el trabajo de la base de datos
Registre las consultas lentas con parámetros y sitios de llamada. Agregue índices solo después de confirmar el patrón de consulta y evite consultas repetidas dentro de los bucles. Realice escrituras por lotes cuando la corrección lo permita. Pruebe 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. Presupuestar los activos transmitidos
Audite texturas de gran tamaño, modelos duplicados y paquetes de recursos que transmiten mucho más de lo que usa el servidor. Pruebe una unión limpia y una ubicación concurrida. Verifique los niveles de detalle, la resolución de la textura y la integridad del archivo antes de comprimir o eliminar activos. Una carga rota puede parecer un problema de rendimiento.
6. Separar 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. Implementar y monitorear
- Haz una copia de seguridad del recurso, la configuración y las tablas de la base de datos afectadas.
- Implementa una corrección medida en el entorno de prueba.
- Repite el escenario de referencia y compara las mismas métricas.
- Lanza durante una ventana controlada y observa los informes de enganches, errores y jugadores.
- 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.