Identificar problemas de desempenho geralmente significa aprofundar-se em uma das três categorias: taxa de quadros (computação), memória ou tempo de carregamento.
O Roblox possui várias ferramentas para identificar problemas de desempenho, algumas das quais estão disponíveis no cliente Roblox (e, portanto, no Studio) e algumas das quais estão disponíveis apenas no Studio. Enquanto você pode observar o comportamento do cliente diretamente, deve usar ferramentas para diagnosticar problemas no servidor.
Ferramentas de diagnóstico
| Ferramenta | Descrição | Localização | Atalho de teclado | Ambiente |
|---|---|---|---|---|
| Console do Desenvolvedor | Um console com mensagens de log em tempo real, erros e informações detalhadas sobre memória, rede e desempenho de scripts. É útil para visualizar o consumo de memória, estatísticas de saúde do servidor, estatísticas de desempenho de scripts e para iniciar o MicroProfiler do cliente ou do servidor. | Studio No Jogo | F9 | Teste no Studio Sessões Ao Vivo |
| MicroProfiler | Uma ferramenta de depuração que detalha quanto tempo computacional é gasto em tarefas a cada quadro. Pode gerar dumps para análise mostrando uma divisão precisa de quadros individuais, tornando-a útil para identificar a tarefa específica que causa problemas de desempenho. Você pode executar o profiler no cliente ou no servidor, dependendo de qual lado tem um problema. | Studio No Jogo | CtrlAltF6 (⌘⌥F6) | Teste no Studio Sessões Ao Vivo |
| Análise de Cena | Fornece informações comparativas rápidas sobre os recursos que suas cenas de cliente e servidor estão usando e quais instâncias são responsáveis por esse uso de recursos. | Studio | N/A | Teste no Studio |
| Estatísticas de Desempenho | Uma barra de ferramentas com estatísticas básicas de desempenho, incluindo consumo de memória, CPU, GPU, dados de rede enviados e recebidos, e tempo de ping. | No Jogo | CtrlAltF7 (⌘⌥F7) | Teste no Studio Sessões Ao Vivo |
| Estatísticas de Depuração | Sobreposições com informações detalhadas sobre gráficos, física, tráfego de rede e FPS. | Studio No Jogo | ShiftCtrlF1 (Shift⌘F1), ShiftCtrlF2 (Shift⌘F2), ShiftCtrlF3 (Shift⌘F3), ShiftCtrlF4 (Shift⌘F4), ShiftCtrlF5 (Shift⌘F5) | Teste no Studio Sessões Ao Vivo |
| Simulação de Rede | Propriedades que simulam condições de rede do mundo real, como latência, jitter e perda de pacotes para testar conexões. | Studio | AltS(⌥S) | Teste no Studio |
| Painel de Desempenho | Um painel com gráficos agregados para uso de memória do cliente e do servidor, taxa de quadros do cliente, batimento cardíaco do servidor e taxas de falha em tempo real. É útil para analisar padrões de desempenho ao longo do tempo. Veja monitorando desempenho. | Painel do Criador | N/A | Sessões Ao Vivo |
Computação do servidor
O batimento cardíaco do servidor é limitado a 60 FPS para todos os jogos, portanto, valores mais baixos podem indicar um problema de desempenho. Para verificar o batimento cardíaco do servidor:
Com o Console do Desenvolvedor - Na aba Server Jobs, expanda a linha Heartbeat e verifique o valor de Steps Per Sec, que representa o batimento cardíaco do seu jogo.
Com o MicroProfiler, você pode verificar o gráfico para ver se o quadro leva mais de 16,67 ms.
Outro sintoma de batimento cardíaco do servidor degradado é o aumento da latência (comumente conhecido como ping). Quanto mais tempo o servidor leva para concluir o cálculo de suas tarefas a cada quadro, mais tempo leva para processar os dados de rede enviados e recebidos dos clientes. Para verificar o ping médio de todos os jogadores conectados a um servidor, vá para a aba Server Stats no Console do Desenvolvedor.
Se o batimento cardíaco do servidor permanecer baixo após você melhorar o desempenho, seu jogo pode precisar de mais CPU do que seus servidores recebem por padrão. Você pode reservar mais com Serviços Estendidos para Computação.
Computação do cliente
O limite padrão da taxa de quadros do cliente é 60 FPS. No entanto, os usuários podem aumentar seu limite de taxa de quadros para até 240 FPS no Windows.
A taxa de quadros varia muito entre os dispositivos. Por exemplo, um PC de alto desempenho pode ser capaz de "forçar" um problema computacional e apenas experimentar uma queda de taxa de quadros imperceptível. Se você testar em dispositivos de menor desempenho, os problemas tendem a ser mais severos e, portanto, mais fáceis de notar.
Para verificar a taxa de quadros do seu jogo:
No cliente, pressione ShiftF5 para mostrar o resumo das estatísticas de depuração.
No menu Window ⟩ Performance do Studio, ative Stats para habilitar as estatísticas de depuração.
Com o MicroProfiler, você pode verificar o gráfico para ver se o quadro leva mais de 16,67 ms.
Memória do servidor
Tente manter o uso de memória do servidor abaixo de 50%. A memória total do servidor usa a seguinte fórmula:
6,25 GiB + (100 MiB * maior_número_de_jogadores_conectados)
Por exemplo, um servidor com 30 jogadores conectados tem aproximadamente 9,18 GiB de memória total. Os servidores ganham memória quando os jogadores se conectam, mas não a perdem quando os jogadores se desconectam. Se 10 jogadores saírem, o servidor ainda terá 9,18 GiB de memória em vez de encolher para 8,2 GiB.
Quando os servidores são desligados (por exemplo, quando estão vazios ou como parte do processo de atualização), suas substituições começam com a quantidade base de memória e começam a aumentar à medida que os jogadores se conectam.
Memória do cliente
Existem várias maneiras de verificar o uso de memória de um jogo:
- Abra o Console do Desenvolvedor e mude para a aba Memory. Esta aba fornece uma divisão de como a memória está sendo alocada. Use o cliente em vez do Studio para obter as leituras mais precisas.
- Ative a visualização Estatísticas de Desempenho no menu de configurações do cliente para ver uma sobreposição com o uso total de memória do cliente.
Um alto uso de memória não é necessariamente indicativo de um problema, mas algumas indicações de que você pode precisar investigar mais são:
- Uma porcentagem significativa de falhas do cliente mostradas no Painel de Desempenho, particularmente um aumento repentino que coincide com uma atualização. Um certo número de falhas é esperado, mas você deve investigar se suas taxas de falha aumentam acima de 2-3%.
- Uma falha ocorre enquanto testa em um dispositivo que você deseja que seu jogo suporte.
Uma parte significativa do consumo de memória de um jogo no cliente vem de ativos, como imagens, malhas e arquivos de áudio, carregados na memória. No Console do Desenvolvedor, verifique os seguintes rótulos em PlaceMemory:
- GraphicsMeshParts - Memória gráfica consumida por malhas.
- GraphicsTexture - Memória gráfica consumida por texturas.
- Sounds - Memória consumida por arquivos de áudio.
Tempos de carregamento
O tempo de carregamento, também chamado de tempo de entrada, é o tempo total desde que um jogador clica em Play até que o mundo seja renderizado e eles possam começar a jogar. Após o cliente se conectar a um servidor, a entrada acontece na seguinte ordem:
- ReplicatedFirst replica para o cliente, e qualquer tela de carregamento personalizada dentro dela aparece.
- O restante do modelo de dados replica, incluindo tudo em ReplicatedStorage e Workspace. Se você ativar streaming de instâncias, apenas a área do Workspace próxima ao ponto de spawn do jogador replica nesta fase.
- O avatar do jogador carrega. O tempo de carregamento termina quando a tela de carregamento desaparece e o mundo começa a renderizar.
Saber qual etapa está lenta ajuda você a escolher as otimizações com maior impacto. Para causas e correções comuns, veja Melhorar desempenho.
Não há ferramentas integradas para verificar os tempos de carregamento, mas como não requerem precisão em milissegundos, um cronômetro geralmente é tudo que você precisa para entender sua linha de base atual e verificar se você fez uma melhoria substancial. Você pode usar um script de cliente em ReplicatedFirst para ter uma noção de como suas mudanças impactam os tempos de carregamento, mas este script não fornece uma medição completa de ponta a ponta. Ele começa a cronometrar após ReplicatedFirst replicar e para quando a replicação inicial termina e DataModel.Loaded é acionado, portanto, não inclui o tempo para se conectar a um servidor ou carregar o avatar:
local startTime = os.clock()
game.Loaded:Connect(function()
local loadTime = os.clock() - startTime
local roundedLoadTime = math.round(loadTime * 10000) / 10000 -- quatro casas decimais
print("Jogo carregado em " .. roundedLoadTime .. " segundos.")
print("Número de instâncias carregadas: " .. #workspace:GetDescendants())
end)Para obter mais informações, ative Imprimir Detalhamento do Tamanho de Entrada na aba Network das Configurações do Studio para imprimir as 20 principais instâncias por tamanho e uma divisão percentual por tipo de instância quando você iniciar o jogo no Studio.
Se o seu tempo de carregamento for inesperadamente alto em relação ao tamanho aparente do seu jogo, inspecione seu lugar em busca de scripts não reconhecidos ou ofuscados. Alguns modelos gratuitos da Loja do Criador contêm scripts que geram milhares de instâncias extras, o que aumenta dramaticamente a quantidade de dados que devem ser replicados quando um jogador entra.
Meça o tempo de carregamento antes e depois de cada otimização ou atualização para que você possa confirmar seu impacto e detectar regressões. Um aumento repentino geralmente significa que o conteúdo foi adicionado recentemente ao ReplicatedStorage ou que uma alteração de ativo aumentou o tamanho do download.
Ping
As duas principais medições de ping (latência) são ping de rede e ping de dados.
O ping de rede é o tempo de ida e volta medido desde que o cliente envia um pacote de dados de rede até que receba a resposta de eco do servidor. É semelhante ao que seria relatado como time pela utilidade de rede ping de propósito geral.
O ping de rede é visível na barra de Estatísticas de Desempenho. É principalmente afetado pelo comprimento do caminho de rede entre o cliente e o servidor, e está fora do seu controle. No entanto, você pode simular ping e outras condições de rede usando simulação de rede ao testar no Studio.
O ping de dados é o tempo de ida e volta medido desde que o cliente envia dados de forma confiável através do sistema de replicação até que receba uma resposta de eco do sistema de replicação do servidor. Inclui o tempo gasto nas filas de replicação do cliente e do servidor, juntamente com retransmissões semelhantes ao TCP de pacotes perdidos ou corrompidos.
O ping de dados é semelhante ao envio de um evento remoto confiável do cliente, recebendo-o no servidor e, em seguida, enviando um evento remoto confiável do servidor para o cliente em resposta. Como o ping de dados também inclui o tempo gasto na rede entre o cliente e o servidor, é maior ou igual ao ping de rede.
O ping de dados médio para todos os jogadores conectados a um servidor é visível na aba Server Stats do Console do Desenvolvedor. O ping de dados para um cliente individual é visível usando ShiftF3 para exibir as estatísticas de depuração da rede.
O ping de dados é afetado tanto pelo caminho de rede quanto pelos atrasos de enfileiramento de replicação. Quando o servidor gera dados de replicação mais rápido do que a rede pode enviá-los (ou mais rápido do que o cliente pode processá-los), os dados devem esperar nas filas de replicação. Alguma diferença entre o ping de dados e o ping de rede é normal devido a retransmissões de rede e à forma como os dados de rede são processados pelo aplicativo Roblox. No entanto, se o ping de dados for significativamente maior que o ping de rede, use o MicroProfiler para visualizar o tráfego de rede. Para sugestões de otimização, veja rede e replicação.