Como saber se a sua base de FiveM precisa de otimização

Quase todo dono de cidade já abriu o resmon, viu um script com número alto e concluiu que a base está pesada. Às vezes está. Muitas vezes não está, e o diagnóstico errado leva a gastar com desenvolvedor sem necessidade, ou a ignorar um problema real.

Neste guia estão os dois comandos que dão o diagnóstico de verdade, e mais importante: como interpretar o que aparece na tela.

Prefere assistir? O processo completo está no nosso tutorial em vídeo. O passo a passo escrito continua abaixo.

Antes: troque o canal de atualizações

As ferramentas de diagnóstico só aparecem completas fora do canal padrão. No FiveM, clique em configurações, vá em Jogo e, em Canal de atualizações, troque de Release para Latest (Unstable).

Reinicie o FiveM depois de trocar.

Não se assuste com o "Unstable" no nome. É a versão mais nova do cliente, feita para quem precisa das ferramentas de desenvolvimento. Você pode voltar para Release depois do diagnóstico, e o canal Beta também serve se preferir algo mais conservador.

O F8 passa a mostrar tudo

Com o canal trocado, entre no seu servidor e aperte F8. O console agora mostra o carregamento inteiro: cada resource iniciando, cada erro, cada aviso.

Só isso já é útil. Rolando um pouco para cima você vê quais scripts subiram e onde algum deles reclamou.

Comando 1: o resmon

No F8, digite:

resmon 1

Se você nunca usou, o passo a passo básico está em como descobrir quais scripts estão pesando. Aqui vamos direto à parte que quase ninguém sabe: ler o número certo.

O número que decide é o de cima

A primeira linha, [Total CPU], na coluna CPU msec, é o diagnóstico. Ela diz quantos milissegundos a sua base está atrasando o processamento a cada tick.

É por aí que você começa, e não pela lista de scripts. Um script com porcentagem alta numa base leve não é emergência. Um total alto é.

Os valores de referência que usamos:

No exemplo acima o total está em 0.64, ou seja, a base está leve. Isso já elimina o pânico de quem olhou a lista e achou que estava tudo errado.

Uma observação importante: acompanhe com a cidade cheia, não vazia. Muito script só mostra o custo real quando tem gente interagindo com ele.

O segundo olhar: quem está fora da curva

Base leve não significa base perfeita. Depois de conferir o total, aí sim vale olhar a lista, com um critério: o consumo bate com o que aquele script faz?

Alguns scripts consomem mais e isso é normal:

• Anticheat, que fica verificando o tempo todo
• Sistemas de loja e VIP, que conversam com serviços externos
• Qualquer script que trabalha pesado com JSON, porque o próprio Cfx cobra mais nesse caso

Agora, quando um script que deveria ser simples aparece com uma fatia grande, tem alguma coisa acontecendo. No exemplo, um sistema de despacho em 23,72% e a pasta do framework em 14,77% não é distribuição normal. Isso quase sempre significa excesso de requisição ou evento sendo disparado repetidas vezes.

Repare no diagnóstico completo: a base está leve e dá para otimizar. Os dois ao mesmo tempo. Reduzir esse desperdício pode derrubar o total de 0.64 para algo perto de 0.30.

Comando 2: o neteventlog

Esse é o comando que quase ninguém usa, e é ele que fecha o diagnóstico.

Ainda no F8, digite:

neteventlog true

Abre uma janela chamada Network Event Log, que mostra em tempo real toda a comunicação entre o cliente e o servidor.

São três colunas:

• Dir: a direção. C->S é o cliente mandando para o servidor, S->C é o servidor mandando para o cliente.
• Name: o nome do evento. É aqui que está o ouro.
• Size: o tamanho em bytes de cada envio.

Como saber se está saudável

O parâmetro é simples e visual: um evento a cada dois segundos, mais ou menos. Surge uma linha, passam dois segundos, surge outra. Se a sua janela se comporta assim, está tudo certo e você não precisa otimizar nada.

O problema é quando a lista não para de rolar, com o mesmo evento aparecendo várias vezes por segundo. Aí não tem discussão: está havendo desperdício de comunicação, e em pouco tempo isso vira megabytes trafegando à toa.

O melhor do comando é o nome

Lembra da pasta do framework com consumo alto no resmon? Olhando a coluna Name, aparecem os culpados com nome e sobrenome: eventos de barbearia, de HUD, de garagem, todos disparando repetidamente.

Isso muda completamente a conversa. Em vez de "minha base está pesada", você passa a saber exatamente qual evento otimizar.

Juntando os dois comandos

O diagnóstico completo sai de três perguntas, nessa ordem:

1. Qual o CPU msec total? Define se existe urgência.
2. Algum script está fora da curva para o que ele faz? Define onde procurar.
3. Que eventos estão se repetindo no neteventlog? Define o que corrigir.

Com as três respostas você sai do achismo. Dá para ter uma base leve e ainda assim otimizar, como no exemplo, e dá para ter certeza de que não precisa mexer em nada.

O que fazer com o diagnóstico

Ajuste a configuração antes de mexer no código. Muito script permite aumentar o intervalo de execução no próprio config, e só isso já resolve boa parte da repetição.

Remova o que você não usa. Script que você testou e esqueceu ligado continua custando.

Procure uma versão mais leve ou atualizada do resource problemático.

Se for chamar um desenvolvedor, chame com o nome do evento em mãos. Essa é a economia real do processo: você deixa de pagar pelo tempo de caçar o problema e paga só pela correção.

E se quiser tentar antes, colar o trecho do script junto do que você viu no neteventlog costuma render um bom ponto de partida com IA. Escrevemos sobre isso em como usar inteligência artificial no seu servidor.

Quando o problema não é a base

Se o total está baixo, nenhum evento está se repetindo e a cidade continua travando com a casa cheia, o gargalo está em outro lugar.

Pode ser a máquina. O que sustenta tick rate é clock por núcleo, e isso não aparece no resmon. Veja como escolher a VPS para o seu servidor de FiveM e, se a suspeita for a hospedagem, os sinais de que é hora de trocar.

Pode ser o download dos arquivos. Se a reclamação é demora para entrar, e não travada dentro do jogo, nenhum dos dois comandos vai mostrar, porque o problema acontece antes de conectar. Quem resolve é o cache externo, que é gratuito nos planos de host de FiveM.