Que hospedagem de servidor dedicado eu preciso para um site de alto tráfego?

Como dimensiono um servidor para um site com muito tráfego?

Parta das requisições por segundo no pico e de quanto tempo cada requisição ocupa um worker, não dos visitantes por mês. Multiplique os dois e você obtém o número de workers ocupados a qualquer instante. A 300 requisições por segundo com 0,1 segundo cada, 30 workers ficam ocupados em média. Dobre isso para os picos.

Os visitantes mensais não dimensionam um servidor; o minuto mais movimentado dimensiona.

• CPU. Uma requisição que faz cálculos usa um núcleo enquanto roda. Workers limitados por CPU precisam de aproximadamente um núcleo cada. Workers que esperam por um banco de dados ou uma API podem ser mais numerosos que os núcleos.
• Memória. Cada worker tem a própria memória. Multiplique o valor por worker pela quantidade de workers e depois some o cache do banco de dados e o sistema operacional.
• Armazenamento. Sites movimentados costumam ser limitados pelo banco de dados. NVMe local mantém consultas e logs fora de discos lentos.

Lumenfer não publica benchmarks, então meça sua própria aplicação. Faça um teste de carga em uma cópia com uma ferramenta como k6 ou wrk e leia o pico de memória por worker no top.

Quantos workers o PHP-FPM, o Node.js e o nginx devem rodar?

Defina o pm.max_children do PHP-FPM pela memória, rode um processo Node.js por núcleo e deixe o nginx iniciar um worker por núcleo.

• PHP-FPM. O manual do PHP diz que pm.max_children limita quantas requisições são atendidas ao mesmo tempo. static mantém essa quantidade de filhos rodando; dynamic e ondemand os iniciam conforme a necessidade. pm.max_requests reinicia os filhos após uma contagem definida, uma solução para bibliotecas com vazamento.
• Node.js. Um processo Node.js executa JavaScript em uma thread. O módulo cluster roda vários processos que compartilham uma porta. O exemplo da documentação dele cria um worker por availableParallelism().
• nginx. O manual do nginx considera um processo worker por núcleo de CPU um bom começo, e auto detecta a contagem. worker_connections tem valor padrão 512 e também conta as conexões de upstream. O limite de arquivos abertos restringe isso, então aumente worker_rlimit_nofile junto.

# /etc/nginx/nginx.conf
worker_processes auto;        # one per CPU core
worker_rlimit_nofile 65535;   # open files per worker
events {
    worker_connections 8192;  # clients and upstreams together
}

# PHP-FPM pool, e.g. /etc/php/<version>/fpm/pool.d/www.conf
# pm = static
# pm.max_children = 64        ; free RAM for PHP / peak memory per child
# pm.max_requests = 1000      ; respawn children to contain leaks

Quanta banda um site com muito tráfego usa?

Menos do que você teme quando um CDN entrega os arquivos estáticos, mais do que você espera sem um. O Web Almanac 2025 do HTTP Archive coloca a página inicial mediana em 2,86 MB no desktop e 2,56 MB no mobile. Os números vêm do rastreamento (crawl) de julho de 2025. Imagens e JavaScript representam a maior parte.

A conta para uma origem sem CDN:

• 1 TB de tráfego carrega cerca de 390.000 carregamentos de páginas iniciais mobile sem cache, a 2,56 MB.
• Uma porta de 1 Gbit/s chega no máximo a 125 MB por segundo: cerca de 49 dessas páginas por segundo.
• Trinta dias em velocidade máxima somam cerca de 324 TB.

No peso mediano de página, uma única origem de 1 Gbit/s chega perto de 49 carregamentos de página sem cache por segundo. Um CDN muda isso: a origem passa a enviar principalmente HTML e respostas de API. Os planos Lumenfer vão de 30 TB por mês a 1 Gbit/s a 150 TB por mês a 1 Gbit/s. Ultrapassar nunca gera cobrança automática.

Preciso de um CDN na frente de um servidor dedicado?

Sim, para qualquer site que espere tráfego de verdade: ele descarrega os bytes estáticos, absorve picos e fica entre os atacantes e a sua origem. A proteção DDoS é limitada ao que a rede do datacenter aplica por padrão; nada além disso é prometido. Um flood enviado ao único endereço IPv4 do servidor chega direto na sua máquina.

Publique apenas os endereços do CDN no DNS e deixe a origem aceitar tráfego web somente do CDN. Nenhum log é mantido: sem logs de conexão, sem logs de tráfego e sem endereços IP de visitantes ou clientes, no site, no painel ou nos servidores. Um CDN que você adiciona mantém os próprios logs sob a própria política, então leia isso antes de escolher um.

Qual CPU é melhor para um site movimentado: clock alto ou muitos núcleos?

Velocidade alta por núcleo para tempo de resposta, mais núcleos para requisições em paralelo. Uma única requisição PHP ou Node.js roda majoritariamente em um núcleo, então a velocidade desse núcleo define a latência. A quantidade de núcleos define quantas requisições rodam no mesmo momento.

Os planos Ryzen combinam menos núcleos com velocidades de clock de desktop. Os planos EPYC adicionam núcleos e memória ECC. Nosso guia do melhor CPU para um servidor alugado compara os dois, e o servidor mais rápido que você pode alugar explica quais critérios decidem a velocidade.

O banco de dados deve rodar no mesmo servidor que o site?

Em uma máquina só, sim, até o banco de dados e os workers começarem a competir por RAM. Hardware compartilhado mantém as consultas locais e custa um único plano. Quando o cache do banco de dados fica apertado, mova o banco de dados para um servidor próprio com memória ECC e conecte os dois via TLS.

Nossa página sobre a melhor hospedagem de servidor para PostgreSQL cobre memória, armazenamento e backups para essa segunda máquina.

Quando um servidor só não basta para um site com muito tráfego?

Quando uma hora de indisponibilidade custa mais do que um segundo servidor. Uma máquina é um ponto único de falha. Não há console IPMI nem KVM-over-IP para clientes: você solicita reinicializações e reinstalações no painel e a equipe as executa. Backups não estão incluídos: mantenha cópias dos seus dados em outro lugar.

Para disponibilidade, rode um segundo servidor em outra cidade com replicação de banco de dados e faça failover via DNS ou pelo seu CDN. Amsterdã (Países Baixos), Reykjavik (Islândia), Zurique (Suíça) e Bucareste (Romênia): todos os cinco planos nas quatro cidades, um preço em todo lugar. Um standby em Zurique ou Reykjavik custa exatamente o mesmo que em Amsterdã.

Na verificação do Lumenfer sobre o 30 October 2026, 27 de 34 vendedores de servidores dedicados precificaram o servidor de entrada com um processador anterior a 2018. Todo plano Lumenfer roda uma CPU de 2022 ou mais recente, DDR5 e NVMe. Compare o custo total com a hospedagem em nuvem em bare metal é mais barato que a nuvem, e veja todos os planos na página de preços Lumenfer.