A opção max-joins-per-tick em config/paper-global.yml limita quantos jogadores podem concluir a entrada no servidor em um único tick. Segundo a documentação atual, jogadores excedentes são adiados para ticks posteriores, não expulsos. Isso pode suavizar picos quando muitas pessoas entram ao mesmo tempo, por exemplo depois de uma manutenção, sem ser o mesmo que controlar tentativas de conexão por IP.

É importante não confundir com connection-throttle em bukkit.yml, que aplica atraso a novas conexões provenientes de um IP conforme sua configuração. Um limita o ritmo de joins processados pelo servidor; outro regula frequência de conexão. Cada um trata uma etapa diferente e tem custos próprios.

Quando um pico de joins se torna problema

Uma entrada em massa pode disparar carregamento de dados de jogador, permissões, inventários, plugins, mensagens de boas-vindas, integração de Discord e sincronização com banco. Mesmo que ticks normais sejam estáveis, uma onda de conexões pode elevar MSPT e criar fila. Reabrir o servidor após evento ou divulgar um link em canais grandes são gatilhos típicos.

Primeiro confirme que o sintoma é de chegada de jogadores. Registre hora, quantidade de tentativas, quantas entradas completam por segundo, MSPT, CPU, memória, consultas a banco e mensagens do log. Um bot ou scan de portas pode gerar conexões que não chegam a login válido; o número de tentativas não equivale a joins concluídos.

Se um plugin executa tarefas pesadas quando cada pessoa entra, limite de joins pode espalhar o trabalho, mas não corrige a lógica ineficiente. Identifique plugins de login, permissões, inventário, claims, chat e integração web. Faça perfil enquanto o pico está ocorrendo, conforme instruções do Paper, e compare o tempo gasto nas rotinas.

Entenda o limite e sua relação com ticks

O máximo é contado por tick. Se mais pessoas entram do que o valor permite, as entradas ficam para ticks seguintes. Em condições normais, o servidor busca 20 ticks por segundo; durante lag, a fila pode avançar mais devagar no tempo real. Por isso, um valor pequeno pode reduzir picos por tick e, ao mesmo tempo, alongar a entrada de uma multidão.

O padrão atual indicado pela documentação de configuração global é 5; referências e arquivos podem mudar com versão. Confirme sua instalação em vez de copiar uma recomendação antiga. O artigo descreve o comportamento, não determina o valor adequado para cada rede.

O limite não representa máximo de jogadores simultâneos nem tamanho de fila garantido. Também não configura capacidade de banco, plugin ou proxy. Se as conexões chegam primeiro a Velocity, o proxy pode ter outros limites e papel no fluxo; cada servidor backend também inicializa seus próprios dados.

Diferencie proteção de abuso e suavização de carga

Para controlar flood ou tentativas repetidas, use defesa em camadas: configuração e firewall do provedor, proxy corretamente protegido, limites de conexão e observabilidade. Não abra backend para acesso direto se a arquitetura exige somente o proxy. A documentação de Velocity recomenda firewall e ressalta que forwarding moderno não o substitui.

Para suavizar joins legítimos, examine também o que ocorre no login. Um valor que retarda toda a comunidade no dia de lançamento pode piorar a experiência sem impedir abuso. Defina qual pico é aceitável e qual ação se toma se o banco ou os plugins não acompanham.

Se o servidor não tem picos nem gargalo de entrada, não há motivo para alterar a configuração. Um parâmetro de controle deve responder a uma necessidade medida, não a um checklist genérico de “otimização”.

Teste com segurança em staging

Duplique a instância e substitua integrações externas por dados de teste. Use clientes autorizados ou um simulador que respeite o protocolo e limites do ambiente; não faça testes de carga em terceiros. Reproduza diferentes ondas de conexão e observe tempo até conclusão, MSPT, carga de CPU, acessos a banco e erros.

Altere somente max-joins-per-tick primeiro. Compare uma entrada gradual e um grupo que chega de repente. Valide que nenhum jogador é chutado por causa do limite e que mensagens, inventários e permissões carregam corretamente. Repetir só o caso de pico ajuda a entender se o gargalo apenas mudou de lugar.

Considere os serviços conectados. Se a cópia de staging usa banco, Discord ou API de produção, entradas de teste podem criar contas, enviar notificações ou modificar dados. Isole credenciais e endpoints antes do teste.

Implemente a alteração e monitore

Confirme a estrutura da configuração global para a versão instalada, pare ou reinicie o servidor conforme exigido e faça backup do arquivo. Preserve indentação YAML. Verifique no log que Paper aceitou a configuração e observe o próximo evento de entrada relevante.

Acompanhe tempo médio para entrar, erros de login, filas de proxy, MSPT e tempo de resposta das integrações. O servidor pode parecer mais estável porque a fila ficou maior; inclua a espera do jogador na avaliação. Se a capacidade não melhora ou a espera fica excessiva, reverta e procure o gargalo no plugin ou serviço.

Comunique janelas de manutenção e comportamento esperado. Em grandes lançamentos, escalone a entrada gradualmente, mantenha equipe de suporte e prepare uma forma segura de voltar. Limites pequenos demais podem fazer jogadores esperarem mesmo quando os recursos estão ociosos.

Documente o resultado

Guarde valor, versão de Paper, número de jogadores testados, cenário e métricas. Registre quando o parâmetro deve ser revisto, como campanhas, reinícios planejados ou migração de banco. Essa evidência impede que valores de um evento excepcional virem configuração permanente sem nova avaliação.

Quando pedir ajuda, envie trecho relevante do log, perfis coletados no momento do problema e versão dos plugins, ocultando endereços ou dados de jogadores. Não publique tokens, forwarding secrets ou credenciais. Esse material ajuda os mantenedores a identificar se o limite está atuando ou se a carga vem de outra etapa.

Coordene abertura, manutenção e filas

Quando uma manutenção termina, publicar em todos os canais ao mesmo tempo pode concentrar entradas num único instante. Combine a abertura com a equipe e, se necessário, anuncie por etapas. Um limite de joins pode suavizar processamento, mas não substitui comunicação e planejamento de capacidade. Informe quanto tempo o login pode levar e como reportar problemas sem insistir em reconexões contínuas.

Observe se reconexões automáticas de clientes ou proxies amplificam a rajada quando há lentidão. Ajuste a mensagem e a estratégia de retry conforme a arquitetura, sem criar uma tempestade de tentativas. Diferencie falha do backend, autenticação externa, fila de conexão e processamento de plugins; cada camada tem sintomas próprios.

Em eventos com lista de espera, mantenha política justa para participantes e verifique se plugins de fila preservam posição durante reinício. Teste que mensagens de boas-vindas, permissões e dados de jogador não atrasam demais o ingresso. A experiência percebida inclui o tempo total desde o clique em “Entrar” até o mundo estar pronto.

Monte um checklist para o próximo pico

Antes da campanha ou evento, confirme capacidade do banco, status do proxy, espaço em disco, backup recente e equipe disponível. Faça uma rodada de entrada com grupo pequeno, observe os indicadores e aumente a carga em estágios. Defina uma condição para pausar divulgação se o login exceder a meta ou se dados não carregarem corretamente.

Durante o pico, alguém deve acompanhar métricas e outra pessoa cuidar de comunicação. Evite reiniciar repetidamente sem causa, pois cada ciclo pode produzir nova rajada. Guarde horários e logs para comparar o resultado com o staging, sem divulgar informação pessoal dos jogadores.

Depois, faça uma retrospectiva simples: quantas conexões chegaram, quantas foram concluídas, quanto tempo esperaram e qual integração consumiu mais tempo. Use os dados para otimizar a causa ou planejar recursos. Se o limite apenas adiou um gargalo de banco, a correção real está na integração ou no dimensionamento, não em aumentar joins por tick.

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.