Configuração e desempenho

Observe primeiro#

Compare detecções com jogo normal antes de kick ou ban. Teste teleporte, respawn e entrega legítima de armas. Sinais do cliente não autorizam dinheiro, armas ou administração.

Controle operações caras#

Deixe varreduras profundas e quarentena automática desligadas até testá-las. Limite capturas simultâneas. A bridge não lê o banco em repouso; HTTPS e outros módulos continuam consumindo recursos. Meça com o profiler FiveM.

Medir uma referência repetível#

Antes de ajustar, profile uma sessão representativa. Anote jogadores, artifact, versões e atividade. Rol tranquilo, garagens lotadas e combate têm cargas diferentes. Compare o mesmo cenário após uma alteração. CPU, hitches e consultas valem mais que promessa de FPS fixo.

Os comandos gravam amostra limitada. Espere terminar e identifique recurso e thread do pico. Nem todo hitch vem do AC. Guarde valores e comparação em privado; amostra curta não cobre todo horário de pico.

profiler record 500
profiler status
profiler view

tosunac_doctor

• Profiler oficial

Controlar custo mantendo proteção#

Teste scans profundos e quarentena automática controladamente. Limite capturas simultâneas e desligue debug em produção. Intervalos menores repetem mais trabalho.

1. Meça repouso e leitura separadamente. A ponte não lê SQL do jogo em repouso, mas HTTPS e outros módulos usam recursos.
2. Pagine listas grandes; confira rejeição de índice com responsável do banco.
3. Meça uma captura teste antes de vários observadores simultâneos.
4. Se aumentar a carga, restaure o ajuste e repita o cenário antes de tocar outros módulos.

• Ponte limitada

Definir punição com contexto#

Observe verificações contextuais e teste jogo normal. Log não exige banir todos. Confira personagem, reanimação, teletransportes, polícia e armas de scripts. Prefira integração específica a isenção permanente.

tosunac_doctor informa valores efetivos arriscados sem alterá-los. Revise punições fortes, proteções desligadas, debug e fail-open. O painel pode substituir valores locais; confira os ativos.

Isenção pode esconder reclamações sem resolver a causa. Liste exceções temporárias, datas e scripts. Após verificar integração remova a exceção e repita o cenário comparando logs.

• Altere um valor e registre motivo, revisão e valor anterior.
• Compare repetições com ações legítimas e horários.
• Reteste após mudança de punição, core ou inventário.
• Com novo falso positivo, restaure e resolva a causa antes de endurecer.

• Integração específica
• Testes de framework

Comparar a mesma carga antes e depois#

Registre jogadores, versões de artifact, AC, framework e inventário, além de operações do painel. Meça primeiro uma sessão tranquila sem solicitações, depois seleção de personagem, garagem e combate normal. profiler record 500 limita a amostra; aguarde profiler status confirmar a conclusão.

Em profiler view identifique resource e thread dos picos de CPU. Observe execuções longas repetidas e avisos hitch associados, além da média. Altere um ajuste e repita sob carga semelhante. Problemas no horário de pico precisam de uma sessão representativa; várias mudanças simultâneas impedem atribuir o resultado.

Medir a ponte de dados separadamente#

Comunicação de saúde não significa consultas constantes de jogadores no banco do jogo quando ocioso. A implementação mantém uma solicitação externa em andamento por vez. O ciclo normal é aproximadamente dez segundos; falhas aumentam a espera até dois minutos. Isso descreve o comportamento atual, não uma opção de velocidade ou prazo garantido de atualização.

Verifique tosunac_db_status no console. Compare uma página de jogadores à medição ociosa. As listas usam páginas de 25 registros e respostas limitadas, não transportam todo o banco. Para unsupported_index ou schema_unavailable, revise esquema e índices compatíveis com um administrador autorizado em vez de forçar consultas maiores.

Anotar aceitação e retorno ao valor anterior#

Defina critérios próprios: nenhum novo hitch persistente, jogo normal concluído e aumentos de duração explicados. Meta universal de FPS ignora equipamentos e outros resources. Um perfil mais rápido não torna detecções incorretas aceitáveis.

Registre valores antigo e novo, horário, jogadores e efeito. Se a carga aumentar, restaure o único ajuste modificado e repita. Não edite saldos para medir. Envie resumo limpo do perfil e avisos do doctor ao suporte. Observe uma sessão normal de produção depois para garantir que condições especiais do teste não ocultaram a carga real.

Separar pico único de trabalho repetido#

Não altere ajustes apenas pela linha mais longa. Examine resource e thread repetidos e ação associada. Preparação única na entrada difere de trabalho a cada tick. Pico na primeira abertura da garagem pede comparar próximas aberturas. Outro resource alterado impede atribuir diferença só ao AC. Amostra curta não representa todas as horas de pico.

Registre duração, frequência e ação juntas. Muitos trabalhos breves acumulam tempo; um longo pode coincidir com hitch. Tempo do profiler servidor não é FPS cliente. Compare travamento cliente ao mesmo intervalo servidor; latência e assets podem exigir outra análise. Peça ajuda com trecho limpo e cenário, em vez de encurtar todos os intervalos por dúvida.

Medir custo da própria observação#

Monitoramento e diagnóstico também criam trabalho. Gravação longa, leituras múltiplas, evidências e debug permanente juntos dificultam atribuição. Limite ferramentas primeiro e compare uma ativa depois. Atualizar vários tabs não mede melhor uma ação; pedidos em horários diferentes e resultados antigos confundem. Escrita de dinheiro não é ferramenta de carga.

Anote sessões da equipe, tela e número de evidências. Compare sessão normal, leitura de jogador e captura eventual separadamente. Desative saída adicional e observe operação normal depois. Reúna dados suficientes para identificar trabalho, não o maior volume. Resultados do servidor atual não garantem outros equipamentos ou jogadores. Confira retirada das opções temporárias ao encerrar manutenção.

Mantenha um pequeno registro diário de saúde#

Num horário representativo parecido a cada dia, faça um registro curto; sessões permanentes de profiler ou capturas não são necessárias. Inclua versão instalada, jogadores atuais, novos erros repetidos de início e estado da ponte quando pertinente. Se houver operação da equipe pendente, examine seu estado em vez de multiplicar leituras iguais para testar disponibilidade. Um fluxo normal do personagem e, quando necessário, uma página formam manutenção menor que percorrer todo o histórico só para juntar dados.

Não salve diariamente toda a configuração inalterada. Compare um aviso novo do doctor ao registro anterior e anote a causa; ele não corrige automaticamente. Reveja uma exceção temporária com seu responsável na data combinada, sem inventar expiração automática. Sem sintomas novos, encerre com a normalidade observada. Para hitch ou erro novo, meça apenas intervalo e ação relacionados. É uma rotina prática do administrador, não uma tarefa automática ou função nova do painel.

Meça crescimento do arquivo separado dos jogadores#

Personagens, veículos e histórico de detecções armazenados podem crescer enquanto aumenta o total conectado. Se o histórico crescer dez vezes com os mesmos jogadores, cronometre primeira página de logs, próxima página e detalhe conhecido separadamente. Se o arquivo ficar igual mas os jogadores aumentarem, avalie o jogo normal. Não altere ambas as variáveis e atribua a diferença somente ao AC. Resultados temporários do painel não significam limpeza automática das tabelas originais de bans ou detecções.

A primeira requisição pode preparar metadados; as seguintes aproveitam cache. Registre amostras frias e quentes separadamente. Paginação e índices limitam transportar o arquivo inteiro de uma vez, mas não eliminam crescimento do armazenamento. Meça a próxima página no mesmo contexto em vez de recarregar a primeira. Se a duração subir claramente, o responsável deve examinar planos e índices numa cópia de testes. Apagar histórico, renomear tabelas ou exportar tudo não é medição. Decida com volume, jogadores e operação medida em conjunto.

Registrar eventos com validação no servidor#

Alterar valores de isenção no cliente não cria isenção geral no servidor. O alívio local de menus/integrações limita-se a movimento/visibilidade; dinheiro, armas e eventos mantêm verificações próprias. Conceda isenções amplas apenas por recursos de servidor confiáveis.

• Registrar eventos com validação no servidor

Verificar permissões e revogação#

ACE, identificadores de administradores e permissões do painel são verificados no servidor. all não é um identificador nem concede acesso. allowedIds usa license:..., discord:... ou fivem:... completos dos identificadores do jogador.

1. Dê apenas as permissões necessárias a um administrador de teste.
2. Remova a permissão do painel e teste o mesmo jogador; o novo intervalo padrão de consulta é cerca de cinco segundos.
3. Confira permissões independentes ACE/admins.lua. Telemetria de jogadores online não concede acesso.
4. Um jogador normal deve continuar bloqueado; use dados de teste para ações sensíveis.

ts.AdminMenu.allowedIds = {
    "license:YOUR_EXACT_PLAYER_IDENTIFIER",
    "discord:YOUR_DISCORD_USER_ID"
}
# Examples are placeholders, not grants.

Evitar análise desnecessária após reiniciar#

Cada arranque verifica impressões SHA256 do conteúdo. Recursos com arquivos e regras inalterados reutilizam resultados autenticados no KVP do servidor, evitando repetir análises dispendiosas de assinaturas e eventos. Mudanças em arquivos, exceções ou regras invalidam a análise correspondente. As impressões ainda leem arquivos; não há garantia de um valor resmon fixo.

1. Mantenha o cache KVP nas atualizações normais; entradas corrompidas ou não verificáveis são analisadas novamente.
2. O catálogo inicial reúne nomes literais de eventos Lua/JS. Nomes dinâmicos, arquivos ilegíveis ou escrow e DLL não são certificados como totalmente analisados.
3. A configuração automática manual aguarda a análise de segurança. Recursos incompletos, suspeitos, alterados ou com tempo esgotado não são aprovados automaticamente.
4. Teste entrada de jogadores, jogo normal e ações administrativas num servidor de teste; avalie resmon com o número de jogadores e a carga do framework.