Não otimizas a performance do CS2 com uma única definição mágica de tickrate, mas sim com FPS de servidor estáveis, condições de rede limpas, número de jogadores adequado e plugins controlados. O sistema Sub-Tick altera a avaliação das discussões clássicas sobre 64 ou 128 ticks: o decisivo é se o teu servidor responde de forma constante sob carga real e se os problemas de ligação podem ser medidos de forma compreensível.
Tickrate, Sub-Tick e gestão de expectativas
O que é tickrate?
A tickrate determina quantas vezes por segundo o servidor calcula o estado do jogo. Em versões mais antigas do Counter-Strike, era um valor de comparação central, porque movimento, registo de acertos e atualizações estavam fortemente ligados a ticks fixos do servidor.
| Tickrate | Atualizações/s | Utilização |
|---|---|---|
| 64 Tick | 64 | Padrão (matchmaking) |
| 128 Tick | 128 | Competitivo (FaceIT) |
Sistema Sub-Tick do CS2
O CS2 usa um novo sistema Sub-Tick:
- As ações são enviadas ao servidor com um carimbo temporal exato
- O servidor calcula o tick e interpola a posição
- Em teoria, a tickrate deveria ter menos influência
Na prática, isto significa: avalia o teu servidor não apenas por um número no parâmetro de arranque. Se os jogadores relatarem delay, rubberbanding ou registo de acertos irregular, verifica primeiro carga da CPU, FPS do servidor, perda de pacotes, variação do ping, complexidade do mapa e interferências de plugins. Um alojamento multi-game pago como game-serverhosting é especialmente útil aqui quando precisas de controlo técnico, suporte e processos operacionais transparentes, em vez de gerires tudo sozinho num root system qualquer.
Como fonte primária oficial, o suporte Steam da Valve é relevante: a documentação Steam sobre Source Dedicated Servers descreve, entre outras coisas, nome do servidor, número máximo de jogadores, porta UDP, RCON e a opção “Secure (Valve Anti-Cheat)”: Documentação em help.steampowered.com. Para arranques de servidor específicos do CS2, o próprio repositório de regras da Valve para setups de Majors menciona SteamCMD com app_update 730 validate e um arranque via ./cs2 -dedicated: Documentação em github.com.
Requisitos antes da otimização
Antes de alterares valores, o servidor deve arrancar de forma reproduzível, estar acessível e funcionar com a tua configuração-alvo. Verifica pelo menos: build atual do servidor, Game Server Login Token correto, porta UDP aberta, rotação de mapas funcional, acesso RCON e um estado inicial documentado do teu server.cfg. Anota também quantos jogadores deverão jogar realisticamente ao mesmo tempo e se estão a correr Workshop maps, plugins de treino, modos Retake, Deathmatch ou setups de torneio.
Problemas de performance só podem ser avaliados corretamente se separares idle de operação durante partidas. Um servidor pode parecer discreto no painel e, ainda assim, quebrar brevemente durante spam de utilitários, muitas entities ou eventos de plugins. Planeia, por isso, um teste com vários jogadores ou bots que se assemelhe ao teu uso real.
Otimização de rede
Os seguintes valores de cliente vêm do setup inicial e podem servir como ponto de verificação se controlas ambientes de cliente ou de treino. Não os uses como solução garantida para tudo; atualizações do CS2 podem alterar o comportamento, e limites do lado do servidor ou ambientes de matchmaking podem tratar os valores de outra forma.
rate 786432
cl_interp 0
cl_interp_ratio 1
cl_cmdrate 128
cl_updaterate 128
O importante é a medição posterior. Presta atenção a ping estável, ausência de perda de pacotes e resposta uniforme em movimento, controlo de spray e peeks. Se vários jogadores da mesma região comunicarem problemas semelhantes, isso aponta mais para temas de servidor, routing ou carga. Se apenas jogadores individuais forem afetados, verifica a ligação deles, Wi-Fi, downloads em segundo plano e distância regional até à localização do servidor.
Medir a performance do servidor
Usa métricas durante uma ronda em curso, não apenas logo após o arranque. Os comandos seguintes servem como pontos práticos de diagnóstico:
sv_showfps 1 # Mostrar FPS
net_graph 1 # Estatísticas de rede
stats # Performance do servidor
Verifica as mesmas situações em cada teste: warmup, ronda cheia, muitas granadas, mudança de mapa e vários matches consecutivos. Se picos de CPU coincidirem exatamente com lags, o ajuste mais provável não é uma cvar de rede, mas sim redução de carga ou mais margem de CPU. Se a RAM ficar curta, observa mudanças de mapa, logs de plugins e uptime prolongado. Noutros jogos, a ponderação é diferente; para contextualizar, encontras planeamento de recursos semelhante no guia sobre performance e RAM de servidores Palworld e no guia para alugar e configurar um servidor Valheim.
Dicas de performance para admins de servidor
- Prioridade da CPU: servidores CS2 pesam na CPU, não na RAM
- Número de jogadores: 5v5 = ideal, 10v10 precisa de mais CPU
- Workshop maps: podem precisar de mais recursos do que mapas padrão
- Limitar plugins: cada plugin custa performance
- Região do servidor: escolhe uma localização perto dos teus jogadores (DE = Frankfurt/Nuremberga)
Implementa estes pontos como sequência de testes. Começa com um mapa padrão e sem plugins adicionais. Se o servidor correr de forma estável assim, ativa extensões uma a uma. Em Workshop maps, presta atenção ao tamanho do ficheiro, densidade de entities, scripting e logs. Em plugins, verifica se são mantidos ativamente e se combinam com a versão atual do CS2. Um plugin que só lança erros ocasionalmente pode, ainda assim, piorar frametimes durante determinados eventos.
Anti-Cheat (VAC) e operação de torneios
O VAC está ativo por padrão em servidores CS2. Para torneios, recomendamos adicionalmente:
- Workshop map com plugin Anti-Cheat
- Ativar GOTV para gravação de replay
Formula expectativas realistas sobre Anti-Cheat: o VAC é o sistema da Valve, mas não substitui uma administração de torneio limpa. Para matches organizados, deves limitar acessos RCON, alterar palavras-passe do servidor regularmente, testar GOTV/CSTV antecipadamente e guardar logs. Com plugins, é preciso cuidado especial, porque nem toda extensão é mantida de forma séria ou continuará compatível com futuras atualizações do CS2.
Verificar o resultado
Um servidor CS2 otimizado mostra FPS de servidor uniformes sob carga real, sem picos de CPU chamativos, ping estável para jogadores da região-alvo e sem erros recorrentes na consola. Documenta a tua configuração funcional com data, número de jogadores, mapa, lista de plugins e comportamento observado. Assim podes comparar de forma direcionada depois de atualizações ou trocas de plugins, em vez de recomeçares do zero a cada relato de lag.
Troubleshooting
Se jogadores relatarem lag, pergunta primeiro por horário, mapa, número de jogadores, ping, loss e se vários jogadores foram afetados ao mesmo tempo. Depois verifica as métricas do servidor no mesmo período. Em problemas após uma atualização, valida os ficheiros do servidor, desativa novos plugins e testa um mapa padrão. Em problemas de routing, ajuda uma localização mais próxima da maioria dos teus jogadores. Se apenas jogadores individuais forem afetados, a causa costuma estar do lado do cliente ou no respetivo fornecedor de internet.
Verificação, limites e caminho seguro de retorno
O guia “Otimizar o tickrate e a performance do servidor CS2” aplica-se ao tipo de servidor descrito no artigo e ao estado de versão visível no momento da verificação. Nomes de menus, versões disponíveis, compatibilidade de mods ou plugins e recursos necessários podem divergir após atualizações. Por isso, não transfiras valores sem verificação para outra versão de jogo, loader ou servidor.
Cria um backup dos ficheiros afetados antes de alterações ao mundo, save, configuração ou extensões. Depois altera apenas um passo relacionado de cada vez e verifica-o com a mesma versão de cliente e servidor com que queres jogar mais tarde.
| Ponto de verificação | Resultado esperado | Cancelamento e retorno |
|---|---|---|
| Arranque do servidor | O servidor atinge o estado pronto para operação sem nova mensagem de erro. | Em erros de arranque, reverter a alteração e restaurar o último backup. |
| Teste de ligação | Uma conta de teste consegue ligar-se através do endereço mostrado no painel. | Em erros de versão ou ligação, comparar novamente versão, porta e permissões. |
| Teste funcional | A função especificamente alterada funciona sem danificar dados existentes do mundo ou do jogo. | Em efeitos secundários, parar o servidor e restaurar os ficheiros guardados. |
Um teste individual bem-sucedido não é garantia de performance ou disponibilidade. Tamanho do mundo, mods, plugins, número de jogadores, caminho de rede e carga simultânea podem alterar o resultado. Documenta versão, alteração e resultado do teste para conseguires compreender desvios posteriores.
FAQ
Posso simplesmente colocar o CS2 em 128 Tick?
O CS2 usa Sub-Tick, por isso a argumentação clássica de 128 ticks do CS:GO não é transferível um para um. Concentra-te em FPS de servidor estáveis, boa ligação e testes reproduzíveis.
Que número de jogadores faz sentido para CS2?
Para matches competitivos clássicos, 5v5 é o tamanho-alvo mais óbvio. Setups maiores como 10v10 podem funcionar, mas precisam de mais margem de CPU e devem ser testados sob carga real.
Workshop maps são um risco para a performance?
Sim, podem precisar de mais recursos do que mapas padrão. Testa novos Workshop maps individualmente e observa CPU, RAM, erros de consola e feedback dos jogadores durante rondas cheias.
Que métricas são mais importantes do que um número de tickrate?
Mais importantes são FPS de servidor estáveis, ping baixo e uniforme, nenhuma perda de pacotes, ausência de picos de CPU e uma consola sem erros durante situações reais de jogo.
Devo instalar muitos plugins?
Só se realmente precisares deles. Cada plugin aumenta a complexidade e pode influenciar a performance ou a estabilidade. Ativa plugins individualmente e documenta o efeito.