Benchmark
Medir a capacidade real do servidor antes de entrar em produção — latência comparada, teste de carga, descoberta do limite sustentado e histórico por hardware.
Onde fica: Monitoramento → Benchmark · rota /benchmark
Permissão: benchmark — Administrador e Operador
É a tela que responde a pergunta que decide a implantação: quanto este servidor aguenta?
O dimensionamento dá uma estimativa a partir do número de assinantes. O benchmark mede o que a máquina do cliente realmente entrega. Rode antes de entrar em produção — é o momento certo para descobrir que falta hardware, não depois do corte.
Pré-requisito: gerador de carga instalado
As abas de Teste de carga, Capacidade e Benchmark Completo dependem do dnsperf
instalado no servidor. Sem ele os botões ficam desabilitados.
sudo apt-get install -y dnsperfA aba de Latência DNS funciona sem ele.
As cinco visões
| # | PT | ES | Responde |
|---|---|---|---|
| 1 | Latência DNS | Latencia DNS | Meu DNS responde mais rápido que os públicos? |
| 2 | Teste de carga | Prueba de carga | Como o servidor se comporta num volume específico? |
| 3 | Capacidade | Capacidad | Qual é o limite antes de degradar? |
| 4 | Benchmark Completo | Benchmark Completo | Uma nota comparável entre os três transportes |
| 5 | Histórico | Historial | O que já foi medido, e em qual hardware |
Para decidir dimensionamento, a aba que importa é a 3 — Capacidade.
Aba 1 — Latência DNS
Compara o tempo de resposta do seu servidor com o de resolvedores públicos, consultando um conjunto de domínios várias vezes em cada um.
| Configuração | Limite |
|---|---|
| Domínios customizados | até 10 |
| Servidores customizados | até 5 |
| Protocolos adicionais | DoT e DoH, se estiverem ativos |
O resultado é um ranking com nota, de A+ a F, composta por velocidade, consistência e confiabilidade. Junto vem a verificação de sequestro de domínio inexistente — um resolvedor que responde endereço para nome que não existe está adulterando respostas.
Os resolvedores do próprio Made4DNS aparecem duas vezes: sem cache e com cache. A diferença entre os dois é justamente o valor do cache local — e é o argumento comercial mais concreto contra usar DNS público.
Serve para mostrar ao cliente que o DNS dele ficou mais rápido. Não serve para dimensionar — para isso, use a aba Capacidade.
Aba 2 — Teste de carga
Gera um volume fixo de consultas por um tempo fixo e mede o que acontece.
Intensidade
| Preset | Volume | Quando usar |
|---|---|---|
| Leve | 1.000 consultas/s por 15 s | Teste de sanidade. Seguro mesmo em produção |
| Médio | 10.000 por 30 s | O equilíbrio para medir o dia a dia |
| Pesado | 50.000 por 60 s | Carga alta. Rode fora do pico |
| Personalizado | manual | Abre as opções avançadas |
Dois modos que medem coisas diferentes
Nas opções avançadas há uma escolha que muda completamente o resultado:
| Modo | O que faz | O número sai |
|---|---|---|
| Performance | 10 domínios em repetição | Otimista — o cache de borda responde quase tudo |
| Carga real | 200+ domínios únicos | Realista — força busca e estressa a resolução |
Um número de "consultas por segundo" medido em modo Performance não representa a capacidade real do servidor: ele mede a velocidade do cache, não a da resolução. Para número honesto, use Carga real.
O alvo também muda o significado
| Alvo | O que está sendo medido |
|---|---|
| Entrada do DNS (porta 53) | O caminho real do cliente, com o cache de borda no meio |
| Recursor direto | Só a resolução, sem o cache de borda |
O produto só aceita endereços locais do próprio servidor como alvo — é proteção contra usar a ferramenta para atacar terceiros.
A trava de segurança
O teste gera carga real de DNS
Se o servidor estiver atendendo mais de 50 consultas por segundo de tráfego real, o produto recusa iniciar o teste. Para prosseguir é preciso marcar explicitamente que você sabe que há clientes reais.
Não desarme essa trava em horário de pico.
O que o resultado traz
Consultas por segundo realmente atingidas, erros, e as latências nos percentis 50, 95 e 99 — o percentil 95 é o que importa, porque descreve a experiência do usuário insatisfeito, não a média.
Junto vem um relatório de recursos comparando antes, durante, no pico e depois: processador, memória, disco e rede.
Aba 3 — Capacidade
É a aba que responde à pergunta do dimensionamento. Em vez de um volume fixo, ela sobe a carga em degraus até o servidor começar a degradar.
O critério do limite
O produto considera o limite sustentado como o maior volume em que, ao mesmo tempo:
- a taxa de erro fica abaixo de 2%, e
- o percentil 95 da latência fica abaixo de 100 ms.
É um critério conservador de propósito: mede o ponto em que o serviço ainda está bom, não o ponto em que ele quebra. A rampa para no primeiro degrau que falha.
Aqui não existe a armadilha do modo otimista
Diferente da aba de Teste de carga, a rampa já usa domínios que forçam falha de cache — ela mede resolução de verdade, não a velocidade do cache. É por isso que esta é a aba certa para dimensionar.
Uma medição real, para servir de referência
Rodamos a rampa num laboratório com o perfil Recomendado da tabela de dimensionamento:
| Item | Valor |
|---|---|
| Máquina | Virtual (KVM), 4 vCPU / 8 GB, Debian 13 |
| Processador do hospedeiro | Intel Xeon E5-2630L v4 a 1,80 GHz |
| Alvo | Entrada do DNS, porta 53, UDP |
| Teto configurado | 50.000 consultas/s, degraus de 15 s |
Os degraus medidos:
| Consultas/s atingidas | Percentil 95 | Erro |
|---|---|---|
| 990 | 64,5 ms | 0% |
| 2.500 | 1,0 ms | 0% |
| 5.000 | 2,1 ms | 0% |
| 10.000 | 3,9 ms | 0% |
| 22.713 | 6,3 ms | 0% |
| 23.430 | 6,1 ms | 0% |
Veredito: limite sustentado de 22.713 consultas por segundo, limitado pelo teto testado.
Ler o campo 'Limitado por' é o que dá sentido ao número
| Valor | Significa |
|---|---|
| erro/timeout ou latência P95 | O servidor saturou. O número é a capacidade real |
| CPU | O processador foi o gargalo |
| teto testado | O servidor não saturou — ele aguenta pelo menos isso, e possivelmente mais |
No exemplo acima o veredito foi teto testado, com erro zero e percentil 95 de 6 ms. Ou seja: a máquina não chegou perto do limite. O gargalo foi o gerador de carga, não o servidor.
Repare também no primeiro degrau: 64,5 ms de percentil 95 a apenas 990 consultas por segundo, e depois 1 ms com o dobro da carga. Não é anomalia — é o cache frio. O primeiro degrau paga a resolução de tudo; os seguintes já respondem da memória.
O número de clientes estimado exige cuidado
A tela exibe um "clientes estimados" ao lado do limite. No exemplo acima, ela mostrou 934.469 clientes para 22.713 consultas por segundo.
Não dimensione a partir desse número
Esse cálculo converte o volume medido em clientes assumindo cerca de 2.100 consultas por dia por cliente, tratando o valor medido como se fosse a média das 24 horas. Mas o que a rampa mede é capacidade de pico, não média.
A regra de dimensionamento do produto vai pelo caminho correto: assinantes × 1,2 = consultas por segundo no pico. Aplicada ao mesmo número:
22.713 ÷ 1,2 ≈ 18.900 assinantes — contra os 934.469 exibidos na tela.
São quase cinquenta vezes de diferença. Dimensionar pelo número da tela levaria a um servidor gravemente subdimensionado.
Para proposta comercial, use a regra de dimensionamento. Use o limite em consultas por segundo desta tela como o dado medido, e faça a conversão por lá.
Aba 4 — Benchmark Completo
Roda três fases em sequência — DNS comum, DNS sobre TLS e DNS sobre HTTPS — e devolve uma nota única, com pesos diferentes por transporte, já que os criptografados custam mais caro.
Serve para comparar execuções ao longo do tempo, ou entre servidores, com um número só. Não substitui a aba Capacidade para dimensionar.
Aba 5 — Histórico
Guarda as execuções anteriores com o hardware junto — e é isso que torna a comparação honesta: um número medido em outra máquina não é comparável.
Permite exportar em PDF e em JSON. Exportar logo após a implantação cria a linha de base: é contra ela que você compara quando alguém disser, meses depois, que "o DNS está mais lento".
Em máquina virtual o número é indicativo
A própria tela avisa: em ambiente virtualizado, a capacidade real depende do hospedeiro físico e de quem mais está nele. Meça de novo se o cliente migrar de hospedeiro.
Armadilhas
- Sem
dnsperf, três das cinco abas não funcionam. - Modo Performance infla o número — use Carga real para medir capacidade.
- Porta de entrada e resolvedor direto medem coisas diferentes.
- "Limitado por: teto testado" significa que o servidor não saturou — o número é um piso, não o limite.
- O "clientes estimados" da tela não serve para dimensionar — veja o aviso acima.
- O primeiro degrau da rampa sempre parece ruim, por causa do cache frio.
- Só endereços locais são aceitos como alvo.
- Não é possível rodar dois testes ao mesmo tempo.
- Em máquina virtual, o resultado é indicativo.
Roteiro — medir a capacidade antes de entrar em produção
Instale o gerador de carga, se ainda não estiver:
sudo apt-get install -y dnsperfAba Capacidade. Confira o banner de carga real — se já houver tráfego de cliente, agende para fora do pico.
Alvo: entrada do DNS na porta 53, que é o caminho real do cliente. Teto de 50.000 para uma máquina do perfil Recomendado, degraus de 15 s.
Inicie e acompanhe a tabela de degraus. Ignore o percentil alto do primeiro degrau.
Leia o veredito e o campo "Limitado por". Se disser teto testado, suba o teto e rode de novo — o servidor ainda não mostrou o limite dele.
Converta em assinantes pela regra de dimensionamento: dividir por 1,2. Não use o número de clientes exibido na tela.
Aba Histórico → exporte em PDF. É a linha de base do cliente.
Se aparecerem recomendações de ajuste, revise em Ajuste fino antes de aplicar.