Dimensionamento
Converter assinantes em QPS, escolher o tier, definir a topologia e medir a capacidade real na homologação.
A unidade de dimensionamento do Made4DNS é o QPS de pico (consultas por segundo). Como o provedor normalmente não mede esse número, o caminho padrão é converter a quantidade de assinantes em QPS estimado e só então escolher a faixa de hardware.
As faixas de QPS são estimativa preliminar
Elas estão ancoradas em um único ponto de medição. Use-as para posicionar o projeto, e sempre preveja uma medição real na homologação antes de fechar o dimensionamento de um ambiente com volume relevante.
De assinantes para QPS
A regra: assinantes ativos × 1,2 = QPS de pico estimado.
O multiplicador é deliberadamente separado em duas partes:
| Parcela | Valor | O que representa |
|---|---|---|
| Base | 1,0 | Premissa de consultas por segundo por assinante ativo no pico. Ainda não medida em produção |
| Margem de segurança | +20% | Folga para absorver a incerteza da base e a variação de perfil da base de assinantes |
| Multiplicador adotado | 1,2 | O número aplicado na prática |
| Assinantes ativos | QPS de pico estimado | Tier sugerido |
|---|---|---|
| até 1.000 | até ~1.200 QPS | Mínimo |
| 1.000 a 5.000 | ~1.200 a 6.000 QPS | Recomendado |
| 5.000 a 20.000 | ~6.000 a 24.000 QPS | Recomendado (com folga) |
| 20.000 a 50.000 | ~24.000 a 60.000 QPS | Ultra |
| acima de 50.000 | acima de 60.000 QPS | Enterprise — avaliar mais de um nó |
Ou informe o número direto:
Estimativa preliminar. Confirme com uma medição real na homologação.
Por que errar para mais
O custo do erro é assimétrico. Subestimar leva a servidor saturado e troca de hardware com o serviço em produção. Superestimar leva a uma máquina virtual um pouco maior — barata e fácil de reduzir depois. Como recomendamos VM, crescer é o que dói; sobrar, não.
A medição de referência
O ponto de partida real que existe hoje:
| Item | Valor |
|---|---|
| Ambiente | Demonstração, VM (KVM) 4 vCPU / 8 GB, Debian 13 |
| Processador do host | Intel Xeon E5-2630L v4 a 1,80 GHz (Broadwell, 2016, baixo consumo) |
| Memória | Plataforma DDR4 |
| Resultado observado | ~41.700 QPS |
| Natureza da medição | Vazão na borda (DNSdist), condição favorável de cache |
| Pontos de medição | Um único ponto |
O que esse número diz: no perfil Recomendado (4 vCPU / 8 GB), o produto sustenta vazão alta quando a maior parte do tráfego é atendida pelo A memória de respostas recentes. Quanto maior a taxa de acerto, mais rápido e mais barato o serviço. — o cenário típico de um ISP em regime.
O que ele não diz: qual é a vazão em recursão fria (respostas que precisam sair para a internet), que é naturalmente menor. O número real de um ambiente fica entre esses dois extremos e depende da taxa de acerto de cache e do mix de consultas.
A base de hardware importa
O número foi obtido em um Xeon de 2016, de baixo consumo e clock base de 1,80 GHz — não é um processador rápido. Em processadores mais novos, o resultado tende a ser igual ou melhor. Em hardware mais antigo ou mais lento que isso, ou com memória DDR3, os requisitos mudam e o dimensionamento precisa ser revisto.
Uma segunda medição, num laboratório
Além do ponto de referência acima, rodamos a rampa de capacidade do próprio produto num laboratório com o perfil Recomendado e o mesmo modelo de processador:
| Item | Valor |
|---|---|
| Máquina | Virtual (KVM), 4 vCPU / 8 GB, Debian 13 |
| Processador do hospedeiro | Intel Xeon E5-2630L v4 a 1,80 GHz |
| Método | Rampa em degraus, na entrada do DNS, com domínios que forçam busca real |
| Resultado | 22.713 consultas por segundo, com erro zero e percentil 95 de 6 ms |
| Limitado por | Teto testado — o servidor não saturou |
Os dois números medem coisas diferentes e não se contradizem: o de ~41.700 é vazão de borda em condição favorável de cache; este é a rampa com o critério de saturação (erro abaixo de 2% e percentil 95 abaixo de 100 ms), forçando resolução real.
E como o veredito foi teto testado, 22.713 é um piso, não o limite — a máquina aguenta pelo menos isso.
Aplicando a regra deste documento: 22.713 ÷ 1,2 ≈ 18.928 assinantes para esse perfil de hardware. É consistente com a faixa "Ultra" da tabela acima, e mostra que o tier Recomendado tem folga confortável para a faixa de 5.000 a 20.000 assinantes.
A tela de Benchmark aplica esta mesma regra
A aba de Capacidade exibe, ao lado do resultado, uma estimativa de assinantes calculada com a regra desta página — QPS de pico ÷ 1,2. São 8.333 assinantes para 10.000 consultas por segundo, e os mesmos 18.928 para o resultado de 22.713 acima.
Ou seja: o número da tela e o da proposta comercial coincidem, e não é preciso converter nada 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 de pico — dá 0,2415 consulta por segundo por assinante, bem abaixo de 1,2. Dimensionar por 1,2 sobra servidor; enquanto houver uma medição só, essa folga fica de pé.
Versões anteriores da tela contavam dispositivo em vez de assinante — cada celular, televisão, computador e roteador separado. A conta não era errada, mas respondia outra pergunta; a razão de cerca de 6× entre as duas é aproximadamente quantos dispositivos existem por domicílio. O erro era chamar de "cliente" tanto o aparelho quanto o assinante.
Topologia por porte
| Cenário | Topologia sugerida |
|---|---|
| Provedor pequeno, sem exigência de alta disponibilidade | Nó único (Recomendado), com backup externo ativo |
| Provedor que exige continuidade | Cluster de 2 nós, cada um dimensionado para o QPS de pico |
| Provedor que opera BGP e quer um único IP de DNS | Anycast sobre o cluster |
| Provedor grande / datacenter | Anycast multi-nó, tier Ultra ou Enterprise por nó |
Cada nó é um servidor a dimensionar e uma licença. Vários servidores respondendo pelo mesmo IP, com o roteamento levando cada consulta ao mais próximo. exige que o provedor opere O protocolo de roteamento entre provedores. É requisito para usar anycast. e só faz sentido com dois nós ou mais.
Como medir a capacidade real
Na homologação, valide o dimensionamento com uma medição de verdade, em vez de confiar só na estimativa:
No painel, abra Monitoramento → Benchmark, que traz abas de Latência DNS, Teste de carga, Capacidade e Benchmark Completo, além do histórico das execuções anteriores.
Para um teste de estresse externo, use o dnsperf contra o IP do servidor na porta 53, por alguns segundos, aumentando a carga até observar o ponto em que começam as perdas.
Acompanhe em tempo real em Dashboard → Servidor (CPU, RAM, disco) e em Dashboard → Performance durante o teste.
Detalhes da ferramenta em Benchmark.
Registre a taxa de acerto de cache e o mix de consultas do teste: são eles que explicam a diferença entre a vazão de borda (alta) e a de recursão fria (menor).