Otimização de servidor FiveM: reduza o lag e melhore o desempenho

Nada mata uma comunidade de roleplay mais rápido que o lag. Os jogadores perdoam funcionalidades ausentes; não perdoam engasgo no meio de uma perseguição. A boa notícia: a maioria dos problemas de desempenho do FiveM tem solução assim que você sabe medi-los. Este guia mostra como.

Primeiro, aprenda a medir: resmon

Você não consegue otimizar o que não enxerga. O monitor de recursos embutido no FiveM é sua ferramenta mais importante.

Abra o console e execute:

resmon

Você verá cada recurso rodando e seu tempo de CPU por frame em milissegundos (ms). É esse o número que importa. Algumas referências:

• Abaixo de 0,5 ms — saudável para um script ativo.
• 0,5–1,0 ms — aceitável, vale uma olhada.
• Acima de 2–3 ms de forma constante — problema; investigue.

Entenda os dois lados do desempenho

O desempenho no FiveM tem um lado servidor e um lado cliente.

• Custo no servidor afeta todo mundo e costuma vir de consultas ao banco, loops grandes e spam de eventos.
• Custo no cliente afeta o FPS de cada jogador e vem de UIs pesadas de renderizar, loops Citizen.Wait(0) constantes e entidades sem culling.

Um recurso pode ser barato no servidor e destruir o FPS do cliente, ou o contrário. Sempre verifique os dois.

As vitórias maiores e mais comuns

1. Elimine loops apertados

O clássico assassino de desempenho no FiveM é uma thread que roda a cada frame sem precisar:

-- Ruim: roda a cada frame, para sempre
CreateThread(function()
  while true do
    Wait(0)
    -- checagens de distância, desenho de marcadores, etc.
  end
end)

A maioria pode esperar mais, dormir quando o jogador está longe, ou ser orientada a eventos. Subir Wait(0) para Wait(500) quando nada acontece pode cortar o custo de um recurso em 90%.

2. Troque polling por eventos

Se um script fica verificando se algo aconteceu, veja se o framework pode avisar em vez disso. Código orientado a eventos dorme até ser necessário e não custa nada enquanto ocioso.

3. Corrija os hábitos com o banco

Consultar o MySQL dentro de um loop, ou a cada tick do jogador, derruba um servidor movimentado. Agrupe consultas, guarde em cache valores que quase não mudam e use os padrões assíncronos do oxmysql direito.

4. Audite suas UIs mais pesadas

A NUI (a camada de interface baseada em navegador) é poderosa e fácil de abusar. Um HUD que re-renderiza sem parar, ou um inventário que nunca limita suas atualizações, come o FPS do cliente em silêncio. Sistemas bem construídos só atualizam o DOM quando os valores realmente mudam.

Escolha recursos base otimizados desde o início

A verdade incômoda: os recursos que você escolhe pesam mais que qualquer ajuste posterior. Seu inventário, HUD e demais sistemas sempre ativos rodam para todo jogador, o tempo todo, então o custo por frame deles define seu piso.

Ao avaliar um recurso sempre ativo, procure:

• Um valor de resmon baixo e estável sob carga (não só ocioso).
• NUI eficiente, que atualiza na mudança e não por temporizador.
• Lógica no servidor que agrupa o trabalho de banco.
• Manutenção ativa e histórico de otimização.

É exatamente por isso que muitas comunidades consolidadas padronizam um conjunto pequeno de sistemas premium comprovados — um inventário bem otimizado como o Quasar Inventory, por exemplo, é projetado para manter a pegada baixa mesmo com a cidade cheia, o que libera seu orçamento de desempenho para o resto. Destrinchamos as principais opções no nosso guia dos melhores inventários.

Um fluxo de otimização repetível

1. Meça a linha de base. Anote o resmon total com um número realista de jogadores.
2. Ordene por custo. Identifique os cinco recursos mais pesados.
3. Investigue o pior. Use o resmon e o profiler do servidor.
4. Corrija ou substitua. Otimize o loop ou troque por uma alternativa mais leve.
5. Meça de novo. Confirme o ganho e repita.

Faça isso todo mês e seu servidor continua rápido enquanto cresce, em vez de degradar aos poucos até os jogadores irem embora.

Checklist rápido de otimização

• Nenhum recurso acima de 2–3 ms sem motivo.
• Wait() escalonado por distância nos scripts de proximidade.
• Lógica orientada a eventos em vez de polling constante.
• Consultas ao banco agrupadas e em cache.
• NUI enxuta e orientada a mudança no HUD e no inventário.
• Auditorias regulares de resmon com a cidade cheia.

Otimização não é tarefa de uma vez só — é hábito. Incorpore cedo, escolha recursos base eficientes, e sua cidade de roleplay vai parecer fluida por maior que fique. Depois, confirme que sua fundação está certa com nossa comparação de frameworks.