Identificar problemas de rendimiento generalmente significa profundizar en una de tres categorías: tasa de fotogramas (cómputo), memoria o tiempo de carga.
Roblox tiene varias herramientas para identificar problemas de rendimiento, algunas de las cuales están disponibles en el cliente de Roblox (y, por lo tanto, en Studio) y algunas de las cuales solo están disponibles en Studio. Mientras que puedes observar el comportamiento del cliente directamente, debes usar herramientas para diagnosticar problemas del servidor.
Herramientas de diagnóstico
| Herramienta | Descripción | Ubicación | Atajo de teclado | Entorno |
|---|---|---|---|---|
| Consola del desarrollador | Una consola con mensajes de registro en tiempo real, errores e información detallada sobre memoria, redes y rendimiento de scripts. Es útil para ver el consumo de memoria, estadísticas clave de salud del servidor, estadísticas de rendimiento de scripts y para lanzar el MicroProfiler del cliente o del servidor. | Studio En el juego | F9 | Pruebas de Studio Sesiones en vivo |
| MicroProfiler | Una herramienta de depuración que desglosa cuánto tiempo computacional se gasta en tareas cada fotograma. Puede generar volcado para análisis mostrando un desglose preciso de fotogramas individuales, lo que resulta útil para identificar la tarea específica que causa problemas de rendimiento. Puedes ejecutar el profiler en el cliente o en el servidor, dependiendo de qué lado tenga un problema. | Studio En el juego | CtrlAltF6 (⌘⌥F6) | Pruebas de Studio Sesiones en vivo |
| Análisis de escena | Proporciona información comparativa de un vistazo sobre los recursos que están utilizando las escenas de tu cliente y servidor y qué instancias son responsables de ese uso de recursos. | Studio | N/A | Pruebas de Studio |
| Estadísticas de rendimiento | Una barra de herramientas con estadísticas básicas de rendimiento, incluyendo consumo de memoria, CPU, GPU, datos de red enviados y recibidos, y tiempo de ping. | En el juego | CtrlAltF7 (⌘⌥F7) | Pruebas de Studio Sesiones en vivo |
| Estadísticas de depuración | Superposiciones con información detallada sobre gráficos, física, tráfico de red y FPS. | Studio En el juego | ShiftCtrlF1 (Shift⌘F1), ShiftCtrlF2 (Shift⌘F2), ShiftCtrlF3 (Shift⌘F3), ShiftCtrlF4 (Shift⌘F4), ShiftCtrlF5 (Shift⌘F5) | Pruebas de Studio Sesiones en vivo |
| Simulación de red | Propiedades que simulan condiciones de red del mundo real como latencia, jitter y pérdida de paquetes para probar conexiones. | Studio | AltS(⌥S) | Pruebas de Studio |
| Panel de rendimiento | Un panel con gráficos agregados para el uso de memoria del cliente y del servidor, tasa de fotogramas del cliente, latido del servidor y tasas de fallos en tiempo real. Es útil para analizar patrones de rendimiento a lo largo del tiempo. Consulta monitoreo de rendimiento. | Panel del creador | N/A | Sesiones en vivo |
Cómputo del servidor
El latido del servidor está limitado a 60 FPS para todos los juegos, por lo que valores más bajos pueden indicar un problema de rendimiento. Para verificar el latido del servidor:
Con la Consola del desarrollador - En la pestaña Trabajos del servidor, expande la fila Latido y verifica el valor de Pasos por segundo, que representa el latido de tu juego.
Con el MicroProfiler, puedes verificar el gráfico para ver si el fotograma tarda más de 16.67 ms.
El MicroProfiler es particularmente útil para identificar "picos" en el rendimiento, donde algunos fotogramas tardan significativamente más que otros en procesarse.
Otro síntoma de un latido del servidor degradado es la latencia aumentada (comúnmente conocida como ping). Cuanto más tiempo tarde el servidor en terminar de calcular sus tareas cada fotograma, más tiempo tardará en procesar los datos de red enviados y recibidos de los clientes. Para verificar el ping promedio de todos los jugadores conectados a un servidor, ve a la pestaña Estadísticas del servidor en la Consola del desarrollador.
Si el latido del servidor se mantiene bajo después de que mejoras el rendimiento, tu juego podría necesitar más CPU de la que sus servidores obtienen por defecto. Puedes reservar más con Servicios extendidos para cómputo.
Cómputo del cliente
El límite de tasa de fotogramas del cliente por defecto es de 60 FPS. Sin embargo, los usuarios pueden aumentar su límite de tasa de fotogramas hasta 240 FPS en Windows.
La tasa de fotogramas varía enormemente entre dispositivos. Por ejemplo, una PC de gama alta podría ser capaz de "forzar" un problema computacional y solo experimentar una caída de tasa de fotogramas imperceptible. Si pruebas en dispositivos de gama baja, los problemas tienden a ser más severos y, por lo tanto, más fáciles de notar.
Para verificar la tasa de fotogramas de tu juego:
En el cliente, presiona ShiftF5 para mostrar el resumen de estadísticas de depuración.
Desde el menú Ventana ⟩ Rendimiento de Studio, activa Estadísticas para habilitar las estadísticas de depuración.
Las estadísticas de rendimiento en Studio están sesgadas por la aplicación de Studio, por lo que deberías ver la tasa de fotogramas en el cliente para obtener números precisos.
Con el MicroProfiler, puedes verificar el gráfico para ver si el fotograma tarda más de 16.67 ms.
Al evaluar la tasa de fotogramas, puede ayudar establecer la calidad gráfica en su valor máximo para eliminar el efecto del administrador de tasa de fotogramas. En el cliente, abre el menú, haz clic en Configuración, cambia Modo gráfico a manual y aumenta la calidad gráfica.
Memoria del servidor
Intenta mantener el uso de memoria del servidor por debajo del 50%. La memoria total del servidor utiliza la siguiente fórmula:
6.25 GiB + (100 MiB * mayor_número_de_jugadores_conectados)
Estos números utilizan potencias de 2, por lo que 1 GiB se refiere a 2^30 bytes y 1 MiB a 2^20 bytes.
Por ejemplo, un servidor con 30 jugadores conectados tiene aproximadamente 9.18 GiB de memoria total. Los servidores ganan memoria cuando los jugadores se conectan, pero no la pierden cuando los jugadores se desconectan. Si 10 jugadores se van, el servidor aún tiene 9.18 GiB de memoria en lugar de reducirse a 8.2 GiB.
Cuando los servidores se apagan (por ejemplo, cuando están vacíos o como parte del proceso de actualización), sus reemplazos comienzan con la cantidad base de memoria y comienzan a escalar a medida que los jugadores se conectan.
Memoria del cliente
Hay varias formas de verificar el uso de memoria para un juego:
- Abre la Consola del desarrollador y cambia a la pestaña Memoria. Esta pestaña proporciona un desglose de cómo se está asignando la memoria. Usa el cliente en lugar de Studio para obtener las lecturas más precisas.
- Habilita la vista de Estadísticas de rendimiento desde el menú de configuración en el cliente para ver una superposición con el uso total de memoria del cliente.
Un alto uso de memoria no es necesariamente indicativo de un problema, pero algunas indicaciones de que podrías necesitar investigar más son:
- Un porcentaje significativo de fallos del cliente que se muestran en el Panel de rendimiento, particularmente un aumento repentino que coincide con una actualización. Se esperan algunos fallos, pero deberías investigar si tus tasas de fallos aumentan por encima del 2-3%.
- Un fallo ocurre mientras pruebas en un dispositivo que deseas que tu juego soporte.
Una parte significativa del consumo de memoria de un juego en el cliente proviene de activos, como imágenes, mallas y archivos de audio, cargados en memoria. En la Consola del desarrollador, verifica las siguientes etiquetas bajo PlaceMemory:
- GraphicsMeshParts - Memoria gráfica consumida por mallas.
- GraphicsTexture - Memoria gráfica consumida por texturas.
- Sounds - Memoria consumida por archivos de audio.
Tiempos de carga
El tiempo de carga, también llamado tiempo de unión, es el tiempo total desde que un jugador hace clic en Jugar hasta que el mundo se renderiza y puede comenzar a jugar. Después de que el cliente se conecta a un servidor, la unión ocurre en el siguiente orden:
- ReplicatedFirst se replica al cliente, y cualquier pantalla de carga personalizada dentro de ella aparece.
- El resto del modelo de datos se replica, incluyendo todo en ReplicatedStorage y Workspace. Si habilitas streaming de instancias, solo el área de Workspace cerca del punto de aparición del jugador se replica en esta etapa.
- El avatar del jugador se carga. El tiempo de carga termina cuando la pantalla de carga desaparece y el mundo comienza a renderizarse.
Saber qué paso es lento te ayuda a elegir las optimizaciones con mayor impacto. Para causas y soluciones comunes, consulta Mejorar el rendimiento.
No hay herramientas integradas para verificar los tiempos de carga, pero dado que no requieren precisión a nivel de milisegundos, un cronómetro es generalmente todo lo que necesitas para entender tu línea base actual y verificar si has hecho una mejora sustancial. Puedes usar un script del cliente en ReplicatedFirst para tener una idea de cómo tus cambios impactan los tiempos de carga, pero este script no proporciona una medición completa de extremo a extremo. Comienza a cronometrar después de que ReplicatedFirst se replica y se detiene cuando finaliza la replicación inicial y se activa DataModel.Loaded, por lo que no incluye el tiempo para conectarse a un servidor o cargar el avatar:
local startTime = os.clock()
game.Loaded:Connect(function()
local loadTime = os.clock() - startTime
local roundedLoadTime = math.round(loadTime * 10000) / 10000 -- cuatro decimales
print("Juego cargado en " .. roundedLoadTime .. " segundos.")
print("Número de instancias cargadas: " .. #workspace:GetDescendants())
end)Para obtener información adicional, habilita Imprimir desglose del tamaño de unión desde la pestaña Red de Configuraciones de Studio para imprimir las 20 instancias principales por tamaño y un desglose porcentual por tipo de instancia cuando inicies el juego en Studio.
Si tu tiempo de carga es inesperadamente alto en relación con el tamaño aparente de tu juego, inspecciona tu lugar en busca de scripts no reconocidos u ofuscados. Algunos modelos gratuitos de la Tienda de Creadores contienen scripts que generan miles de instancias adicionales, lo que aumenta drásticamente la cantidad de datos que deben replicarse cuando un jugador se une.
Mide el tiempo de carga antes y después de cada optimización o actualización para que puedas confirmar su impacto y detectar regresiones. Un aumento repentino a menudo significa que se agregó contenido recientemente a ReplicatedStorage o que un cambio de activo aumentó el tamaño de descarga.
Ping
Las dos mediciones principales de ping (latencia) son ping de red y ping de datos.
El ping de red es el tiempo de ida y vuelta medido desde que el cliente envía un paquete de datos de red hasta que recibe la respuesta de eco del servidor. Es similar a lo que se informaría como time por la utilidad de red ping de propósito general.
El ping de red es visible en la barra de Estadísticas de rendimiento. Se ve mayormente afectado por la longitud de la ruta de red entre el cliente y el servidor, y está fuera de tu control. Sin embargo, puedes simular el ping y otras condiciones de red usando simulación de red al probar en Studio.
El ping de datos es el tiempo de ida y vuelta medido desde que el cliente envía datos de manera confiable a través del sistema de replicación hasta que recibe una respuesta de eco del sistema de replicación del servidor. Incluye el tiempo pasado en las colas de replicación tanto del cliente como del servidor, junto con retransmisiones similares a TCP de paquetes perdidos o corruptos.
El ping de datos es similar a enviar un evento remoto confiable desde el cliente, recibirlo en el servidor y luego enviar un evento remoto confiable desde el servidor al cliente en respuesta. Debido a que el ping de datos también incluye el tiempo pasado en la red entre el cliente y el servidor, es mayor o igual al ping de red.
El ping de datos promedio para todos los jugadores conectados a un servidor es visible en la pestaña Estadísticas del servidor de la Consola del desarrollador. El ping de datos para un cliente individual es visible usando ShiftF3 para mostrar estadísticas de depuración de red.
El ping de datos se ve afectado tanto por la ruta de red como por los retrasos en la cola de replicación. Cuando el servidor genera datos de replicación más rápido de lo que la red puede enviarlos (o más rápido de lo que el cliente puede procesarlos), los datos deben esperar en las colas de replicación. Algunas diferencias entre el ping de datos y el ping de red son normales debido tanto a las retransmisiones de red como a la forma en que la aplicación de Roblox procesa los datos de red. Sin embargo, si el ping de datos es significativamente más alto que el ping de red, usa el MicroProfiler para ver el tráfico de red. Para sugerencias de optimización, consulta redes y replicación.