Comece medindo a falha. Baixo FPS do cliente, alto tempo de recurso, travamentos do servidor, esperas de banco de dados e perda de rede são problemas diferentes. Capture uma linha de base repetível em uma contagem representativa de jogadores antes de remover recursos ou copiar convars de outro servidor.
Método: revisado em 9 de agosto de 2026 com base no guia do profiler, nos comandos de console do cliente e nos comandos de servidor oficiais da Cfx.re.
1. Defina o sintoma e a linha de base
- A queda de FPS de um jogador: reproduza nesse cliente e inspecione o monitor de recursos do cliente.
- Todos os jogadores travam: registre avisos de lentidão do servidor, tempo de recurso, latência do banco de dados e saturação da CPU do host.
- A entrada é lenta: inspecione o tamanho do ativo transmitido, o comportamento de download e o trabalho de inicialização.
- Ações atrasam: rastreie o evento e a consulta do banco de dados em vez de culpar os gráficos.
Registre a versão do artefato, contagem de jogadores, recursos ativos, rota de teste e carimbos de data/hora. Altere uma variável por vez.
2. Use o resmon e o profiler corretamente
Em uma configuração de desenvolvimento permitida, abra F8 e use resmon true para uma comparação rápida do lado do cliente. O Cfx.re classifica o resmon como um comando de desenvolvedor; um cliente normal pode negar o acesso. Trate-o como um indicador, não um veredito: o tempo varia com o que o jogador está fazendo. Reproduza a mesma interação várias vezes. Para evidências em nível de código, faça uma captura do profiler durante a ação lenta e inspecione o escopo ou evento caro.
Mantenha o guia detalhado do resmon no FiveM aberto durante os testes.
3. Corrija o código do recurso no gargalo
- Substitua loops incondicionais por quadro por trabalho orientado a eventos ou um intervalo de espera justificado.
- Valide eventos de rede no servidor e envie apenas os dados que o cliente precisa.
- Evite transmitir grandes cargas úteis quando um evento direcionado for suficiente.
- Armazene em cache pesquisas estáveis, mas invalide o cache quando o estado subjacente mudar.
- Analise antes e depois; um código mais curto não é automaticamente um código mais rápido.
4. Verifique o trabalho do banco de dados
Registre os tempos de consulta lenta e os locais de chamada; oculte credenciais e dados de jogadores de quaisquer exemplos de consulta compartilhados. Adicione índices somente após confirmar o padrão de consulta e evite consultas repetidas dentro de loops. Agrupe as gravações quando isso não comprometer a correção dos dados. Teste reconexões, salvamentos programados e ações econômicas de pico, pois um banco de dados de teste vazio pode ocultar a latência de produção.
5. Defina limites para os recursos transmitidos pelo servidor
Audite texturas superdimensionadas, modelos duplicados e pacotes de recursos que transmitem muito mais do que o servidor usa. Teste uma conexão com um cliente limpo e um local movimentado. Verifique os níveis de detalhe, resolução da textura e integridade do arquivo antes de compactar ou remover ativos. Um upload corrompido pode parecer um problema de desempenho.
6. Separar limites do host de limites do script
Observe a saturação da CPU por núcleo, a pressão da memória, a latência do armazenamento, a perda de pacotes e a localização do banco de dados. As cargas de trabalho FiveM podem sobrecarregar um núcleo ocupado enquanto o total da CPU ainda parece baixo. Compare hosts com a mesma compilação e carga; RAM e slots anunciados por si só não comprovam capacidade.
7. Implementar e monitorar
- Faça backup do recurso, da configuração e das tabelas de banco de dados afetadas.
- Implante uma correção medida para o ambiente de teste.
- Repita o cenário de linha de base e compare as mesmas métricas.
- Lance durante uma janela controlada e acompanhe os travamentos, os erros e os relatos dos jogadores.
- Reverta imediatamente se a métrica alvo ou o fluxo de jogo regredir.
A otimização só é completa quando o sintoma medido melhora sem mover a falha para outro lugar.