Medir a capacidade do servidor
Descobrir quantas consultas por segundo o servidor sustenta de verdade, antes de apontar assinantes para ele.
É a pergunta que decide o dimensionamento: quantas consultas por segundo este servidor aguenta? O teste de capacidade responde medindo, não estimando — sobe a carga em degraus até o servidor deixar de sustentar, e reporta o último degrau que ele sustentou.
Faça antes de apontar os assinantes. Depois, o servidor está em produção e o teste passa a competir com tráfego real.
Antes de começar
O gerador de carga precisa estar instalado no servidor. A tela avisa se ele faltar, com o comando de instalação.
Escolha uma janela de baixo movimento. A carga é real: o servidor vai trabalhar de verdade.
Decida qual camada medir — a entrada do DNS ou o Outro nome para o servidor recursivo: o endereço de DNS que o assinante configura. direto. São números diferentes, e a diferença entre eles é justamente o custo da camada de entrada.
Onde clicar, passo a passo
As outras abas respondem outras perguntas: latência compara servidores, teste de carga usa um volume fixo. Capacidade é a única que procura o limite.
A tela declara o critério: capacidade sustentada é o maior volume com erro abaixo de 2% e latência p95 abaixo de 100 ms.
E usa domínios que forçam falha de cache de propósito. Medir com cache quente daria um número bonito e inútil — mediria a memória, não a capacidade de resolver.
| Alvo | Mede |
|---|---|
| Entrada do DNS (porta 53) | O caminho completo, como o assinante vê. É o número que vale para dimensionar |
| Recursor direto (porta 5301) | Só o resolvedor, sem a camada de entrada |
Testar os dois e comparar mostra quanto a camada de entrada custa. Para dimensionamento, use a entrada do DNS.
O protocolo também importa: UDP é o transporte da maioria esmagadora das consultas. DoT e DoH custam mais caro por consulta, então meça neles se for oferecê-los.
O teto é onde a rampa para de subir, mesmo que o servidor ainda aguente. Comece alto o bastante para o servidor saturar antes do teto — senão o resultado mede a sua escolha, não o servidor.
A duração por degrau é quanto tempo cada nível é sustentado. Degraus curtos medem rápido; degraus longos capturam problemas que só aparecem depois de alguns segundos de carga.
A rampa gera carga crescente real no alvo. Num servidor em produção isso degrada o serviço dos assinantes enquanto o teste roda.
Cada linha traz o volume pedido, o volume efetivamente entregue, a latência p95, a taxa de erro e o uso de processador.
A coluna de processador é a mais informativa durante a subida: quando ela se aproxima de 100%, o próximo degrau provavelmente falha. DNS é limitado por processador — é lá que o teto aparece.
A rampa para no primeiro degrau que falha. Não insiste.
Três números, e o terceiro é o que muda a leitura dos outros dois.
Limitado por diz o que interrompeu a subida:
| Valor | Significa |
|---|---|
| teto testado | O servidor não saturou — parou porque chegou no teto que você escolheu. A capacidade real é maior. Refaça com teto mais alto |
| CPU | Chegou no limite de processamento. É o resultado esperado num teste bem feito |
| latência P95 | Ainda responde, mas devagar demais |
| erro/timeout | Começou a perder consultas |
No exemplo acima o resultado é teto testado: o servidor sustentou os 10.000 pedidos com 0% de erro e processador em 52%. Ele aguenta mais — só não foi perguntado.
Assinantes estimados usa a mesma regra do dimensionamento
Ao lado da capacidade, a tela mostra uma estimativa de assinantes — e ela sai da mesma conta da página de dimensionamento: pico ÷ 1,2. No exemplo acima, 10.000 consultas por segundo viram cerca de 8.333 assinantes.
Ou seja: o número da tela e o da proposta comercial são o mesmo número. Não há conversão a fazer entre um e outro.
A regra é conservadora de propósito. O único ponto de campo que existe hoje — um provedor com 90 mil assinantes marcando 21.733 consultas por segundo no pico — dá 0,2415 consulta por segundo por assinante, bem abaixo de 1,2. Enquanto houver uma medição só, a folga fica de pé.
E continua sendo estimativa: ela vale tanto quanto o número de consultas por segundo medido naquele hardware.
O resultado fica registrado com o hardware do servidor junto — e é assim que ele deve ser lido. O mesmo número em máquinas diferentes significa coisas diferentes.
Repare no aviso de ambiente virtualizado: numa máquina virtual, a capacidade depende do hospedeiro físico e de quem mais está nele. O número é indicativo, não garantido.
O histórico exporta em PDF e em dados brutos — útil para anexar a uma proposta ou a um laudo de aceitação.
Depois de medir
Se o resultado veio como teto testado, repita com um teto mais alto. Você ainda não achou o limite.
Se veio limitado por CPU, esse é o número real da máquina. Anote junto com o hardware.
Se veio limitado por latência ou erro bem abaixo do esperado para o hardware, há provavelmente ajuste a fazer antes de aceitar o número — veja ajustar o desempenho.
Meça de novo depois de qualquer ajuste. Sem o antes e o depois, não dá para saber se o ajuste ajudou.
Armadilhas
- Teto baixo demais faz o teste medir a sua escolha, não o servidor.
- Medir com A memória de respostas recentes. Quanto maior a taxa de acerto, mais rápido e mais barato o serviço. quente infla o número. O teste evita isso sozinho, mas se você montar um teste próprio, lembre.
- Rodar em produção degrada o serviço enquanto mede.
- Comparar números entre hardwares diferentes sem olhar o hardware não diz nada.