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.
Passo a passo ilustrado
Abaixo cada visão é descrita em detalhe. Para rodar a medição inteira, com um print por etapa, siga Medir a capacidade do servidor.
Desde a versão 0.37.0: aviso quando o certificado não é confiável
O dnsperf, ferramenta que mede a carga, não valida certificado ao testar DoT ou DoH: ele mede a
velocidade da conexão TLS, não se um cliente real aceitaria aquele certificado. Sempre que o
certificado ativo é autoassinado ou tem a cadeia incompleta, as abas Teste de carga,
Capacidade e Benchmark Completo mostram um aviso de que o número medido não representa a
experiência de um assinante de verdade, que recusaria a conexão antes mesmo de consultar. Emita
um certificado válido em Let's Encrypt antes de medir
DoT/DoH para produção.
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.
Gerar a carga na mesma máquina subestima o servidor
Desde a 0.36.1 a tela avisa quando o número que ela mostra está por baixo. O motivo: gerar carga e responder no mesmo servidor mede disputa de CPU, e o resultado sai de 4 a 10 vezes abaixo do real.
A ressalva acompanha o histórico e o PDF, e não só a tela, porque é esse número que alimenta a tabela de dimensionamento que vai na proposta comercial.
Para medir de verdade, gere a carga de outra máquina. Veja medir capacidade.
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 assinantes estimados, e de onde ele sai
A tela exibe uma estimativa de assinantes ao lado do limite, cerca de 8.333 para 10.000 consultas por segundo, por exemplo. Ela sai da mesma conta da página de dimensionamento: QPS de pico ÷ 1,2.
Capacidade sustentada (QPS): o maior volume com erro abaixo de 2% e P95 abaixo de 100 ms.
Assinantes estimados (pico): é a capacidade sustentada dividida por 1,2.
Limitado por: teto testado quer dizer que o servidor não saturou.
A nota de rodapé: imprime a regra usada e lembra que é medição, não garantia.
A tela e a proposta comercial mostram o mesmo número
Não há conversão a fazer entre a tela e o documento comercial: as duas trabalham com
assinantes = QPS de pico ÷ 1,2. Aplicando ao limite medido acima: 22.713 ÷ 1,2 ≈ 18.928
assinantes.
A regra é conservadora de propósito. O único ponto de campo existente (um provedor com 90 mil assinantes e 21.733 consultas por segundo de pico) dá 0,2415 consulta por segundo por assinante, muito abaixo de 1,2. Dimensionar por 1,2 sobra servidor, e enquanto houver uma medição só, a folga fica de pé.
Continua sendo estimativa: o número de assinantes só vale tanto quanto o número de consultas por segundo que a rampa mediu naquele hardware.
Versões anteriores da tela contavam dispositivo em vez de assinante, cada celular, televisão, computador e roteador separado. Não era uma conta errada, mas respondia outra pergunta: a razão de cerca de 6× entre as duas é aproximadamente quantos dispositivos existem por domicílio. O problema era chamar de "cliente" tanto o aparelho quanto o assinante. Hoje a tela conta assinante: o domicílio ou o contrato.
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 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.
Leia a estimativa de assinantes ao lado do limite. Ela já é o limite dividido por 1,2, a mesma regra de dimensionamento, então é esse número que vai para a proposta, sem conversão.
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.