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 contra o Cfx.re oficial guia do profiler, comandos do console do cliente e comandos do servidor.
1. Defina o sintoma e a linha de base
- Quedas 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
Abra F8 e use resmon 1 para uma rápida comparação do lado do cliente. 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 os detalhes guia de resmon do FiveM abertos durante o teste.
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 consultas lentas com parâmetros e locais de chamada. Adicione índices somente após confirmar o padrão de consulta e evite consultas repetidas dentro de loops. Agrupe as gravações quando a correção permitir. Teste reconexões, salvamentos programados e ações de pico de economia porque um banco de dados de teste vazio pode ocultar a latência de produção.
5. Orçamento de ativos transmitidos
Audite texturas superdimensionadas, modelos duplicados e pacotes de recursos que transmitem muito mais do que o servidor usa. Teste uma junção limpa 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 observe os relatórios de travamentos, erros e 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.
