Calculadora de Recursos VPS

Não é o nome do pacote, é o comportamento da carga

Ao escolher um VPS, o nome do pacote engana facilmente. “Basic”, “standard”, “premium”, “general purpose”… Parecem bons. Mas nenhum desses nomes, sozinho, diz quanto de RAM o site vai consumir, quando vai sufocar a CPU ou em que dia o disco vai encher.

Um site estático e uma loja WooCommerce, mesmo recebendo o mesmo visitante, não precisam do mesmo servidor. Em um, arquivos prontos são servidos; no outro, há carrinho, pagamento, estoque, sessão de usuário, consultas ao banco de dados, painel administrativo e, às vezes, trabalhos em fila rodando em segundo plano. A diferença está exatamente aqui.

Este modelo de cálculo lê o VPS por quatro recursos principais: vCPU, RAM, disco e tráfego mensal. Mas não os trata como números crus; avalia junto com o tipo de aplicação, o nível do ambiente, o uso de cache/CDN, os serviços que rodam no mesmo VPS, logs, backups locais e a margem de crescimento.

Não existe uma “fórmula oficial de VPS”. Nos documentos dos grandes provedores de nuvem, a questão também é tratada assim: CPU, memória, rede e armazenamento são considerados juntos; as famílias de máquinas também são separadas por carga de trabalho. Máquinas de uso geral se comportam de um jeito, máquinas com foco em computação de outro, e máquinas com foco em memória de outro. No lado do VPS, vale a mesma lógica, só que em escala menor.

flowchart LR
  A["Tipo de aplicação"] --> E["Estimativa de recursos"]
  B["Tráfego e cache"] --> E
  C["Banco de dados, worker, painel administrativo, Docker"] --> E
  D["Disco, logs, backups, margem de crescimento"] --> E
  E --> F["vCPU"]
  E --> G["RAM"]
  E --> H["Disco"]
  E --> I["Tráfego mensal"]

A frase que mais detesto nesse tipo de cálculo é: “2 vCPU são suficientes.” Suficiente para quê? Para um site estático, WooCommerce, Odoo, uma API Node.js ou para uma instalação mista com MySQL, Redis, e-mail e Docker no mesmo servidor?

Além disso, a diferença entre CPU compartilhada e CPU dedicada passa despercebida. Em planos VPS pequenos, a CPU quase sempre é compartilhada. Para sites leves, pode não ser problema. Mas em sistemas que rodam workers regularmente, recebem tráfego de pico, geram relatórios ou sobrecarregam o banco de dados com frequência, o mesmo número de vCPUs pode parecer mais fraco do que o esperado.

Por isso, a saída aqui não deve ser lida como um “plano definitivo”, mas como uma estimativa inicial segura. Ela dá uma boa primeira visão para a escolha de recursos. Em produção, a palavra final é sempre das métricas: uso de CPU, consumo de RAM, ocupação do disco, tráfego de rede, consultas lentas, logs de erro e fila de workers.

O papel é uma coisa, o servidor é outra.

Por onde começamos?

A primeira divisão do cálculo vem do tipo de aplicação. Porque a carga base de cada classe de aplicação não é a mesma.

O site estático está no lado mais leve. Assume-se CPU base de 1 vCPU, RAM base de 1 GB; o fator de CPU também é mantido baixo, em 0.2. Isso faz sentido. Porque em um site estático bem cacheado, o servidor, na maioria das vezes, serve arquivos prontos, e a camada de aplicação trabalha muito pouco.

Para WordPress/blog, o ponto de partida sobe: CPU base de 1.5 vCPU, RAM base de 2 GB, fator de CPU 1. O WordPress tem PHP e banco de dados na base. Tema, plugins, processamento de imagens, operações administrativas, busca, comentários... ele não se comporta como um site estático. Ainda assim, com um bom cache, pode ser bastante aliviado.

WooCommerce/e-commerce é outra classe. Neste modelo, assume-se CPU base de 2.5 vCPU, RAM base de 4 GB e fator de CPU 2. Na minha opinião, essa distinção é essencial para e-commerce. Porque o WooCommerce coloca, sobre o WordPress comum, uma camada de carrinho, pagamento, pedidos, estoque e assinaturas. Além disso, algumas páginas não são totalmente adequadas para cache. A página de produto pode vir do cache, mas no carrinho e no checkout a história muda.

Para aplicações Laravel/PHP e Node.js/API, a CPU base é 2 vCPU, RAM base 3 GB e fator de CPU 1.2. Aqui, a necessidade real depende muito do código. Uma API simples pode funcionar de forma bem leve; uma aplicação que conversa com serviços externos, processa dados continuamente e usa filas pode ser muito mais pesada na mesma classe.

Para SaaS pequeno, CPU base 3 vCPU, RAM base 4 GB, fator de CPU 1.8. Sessão de usuário, tarefas em segundo plano, notificações, relatórios e tráfego de banco de dados geralmente vêm juntos. O número de visitantes parece pequeno, mas as operações internas da aplicação são muitas. Se você olhar como se fosse um site, escolhe o pacote errado.

Sistemas tipo Odoo/ERP estão no lado pesado: CPU base 4 vCPU, RAM base 8 GB, fator de CPU 3. Em instalações Odoo, o planejamento de workers e memória já é pensado à parte. Relatórios, sessões de usuário, módulos, operações de banco de dados e tarefas demoradas diferenciam essa classe de um blog comum.

Para servidor de jogo, CPU base 3 vCPU, RAM base 4 GB, fator de CPU 2.5; no lado do bot/worker, assume-se CPU base 2 vCPU, RAM base 2 GB, fator de CPU 1.5. Em trabalhos do tipo worker, especialmente, o número de visitantes pode enganar. Mesmo que ninguém acesse o site, há processamento de dados em segundo plano.

A escolha do ambiente entra como um coeficiente sobre o valor base. Ambiente de teste/hobby: 0.75; produção pequena: 1; produção: 1.25; preparação para alta disponibilidade: 1.6. Preparação para alta disponibilidade não significa “um único VPS agora virou HA”; significa apenas deixar uma margem de recursos maior. HA de verdade exige uma arquitetura separada.

A margem de crescimento entra no final. O padrão é 30%. Acho razoável. É uma boa faixa para absorver uma expectativa de crescimento de 3 a 6 meses. Você pode colocar 300%, mas, se não houver esse crescimento previsto, o cálculo vira cálculo do medo.

Cálculo de tráfego: a média mensal engana um pouco

O número de visitantes mensais é o primeiro dado a olhar, mas é fraco para a decisão final. Dois sites com 100 mil visitantes podem não gerar a mesma carga. Um mostra 1.5 página por visitante, com páginas de 1 MB, e o CDN funciona bem. O outro mostra 4 páginas por visitante, com páginas de 3 MB e muitas áreas dinâmicas. Mesmo visitante, carga de servidor completamente diferente.

O cálculo de tráfego considera juntos o número de visitantes, o valor de páginas por sessão e o tamanho médio da página. Em seguida, desconta o efeito do cache, adiciona a margem de crescimento e converte o resultado para GB. O valor final é arredondado para faixas de 50 GB; mesmo em cenários muito pequenos, é exibido um tráfego mínimo de 50 GB.

As premissas usadas para o cache são estas: sem cache, economia 0; cache básico, 35%; cache de página + object cache, 60%; CDN + cache forte, 75%. Esses não são valores oficiais garantidos. Quando se usa cache NGINX ou CDN, espera-se que a carga no servidor de origem diminua; porém, a economia real depende da taxa de hit do cache, da estrutura da página e das áreas dinâmicas.

Preste atenção especialmente no WooCommerce. O fato de haver CDN não faz o carrinho e o checkout ficarem de graça. Em lugares como conteúdo personalizado, sessão, operações administrativas, fluxo de pagamento e controle de estoque, o cache é mais limitado. O cache é um bom freio; não substitui o motor.

Existe também o fator de horário de pico. O tráfego mensal não se distribui uniformemente. Dia de campanha, envio de newsletter, compartilhamento em redes sociais, picos repentinos em sites de notícias... Enquanto a média parece calma, o servidor pode suar por uma hora. Neste cálculo, o pico de RPS é encontrado aproximadamente dividindo (visitantes mensais × páginas por sessão × fator de pico) pelo número de segundos em 30 dias. 30 dias são 2.592.000 segundos.

O efeito do tráfego na CPU é ainda mais interessante. O número de visitantes é proporcionalizado a 50.000, multiplicado pelo fator de carga da CPU, soma-se o fator de pico e desconta-se metade do efeito do cache no lado da CPU. Ou seja, o cache reduz o tráfego de forma significativa, mas o efeito na CPU é reduzido com mais cautela. Acho que é a abordagem certa; porque nem toda requisição vem do cache.

No teste de site estático cacheado, com 100 mil visitantes mensais, 1.5 páginas por sessão, 1 MB de tamanho de página, fator de pico 2, CDN + cache forte e margem de crescimento de 20%, o resultado fica no nível de 1 vCPU, 2 GB de RAM, 40 GB de disco e 50 GB de tráfego mensal. Há tráfego, mas a carga é leve.

No exemplo de e-commerce, não há esse conforto. Com 200 mil visitantes mensais, 4 páginas por sessão, tamanho médio de página de 3 MB, fator de pico 5, cache de página + object cache e margem de crescimento de 50%, o tráfego mensal chega a 1450 GB. A sugestão de CPU é de 32 vCPUs. À primeira vista, pode parecer alto; mas, somando os números, o quadro fica mais duro: mais visitantes, mais páginas, páginas maiores, carga de trabalho mais pesada e pico mais alto.

O tamanho da página é outro problema. Dizer “o site é leve” não basta; é preciso medir. Imagens grandes, fontes, scripts de terceiros, códigos de anúncio, tags de analytics e arquivos JS desnecessários incham o tráfego. O fato de abrir rápido no navegador não significa que a transferência de dados seja pequena.

Quem está rodando na mesma máquina?

Em VPS pequenos, a briga de verdade geralmente acontece aqui. O servidor web não fica sozinho. O MySQL está no mesmo lugar, o Redis também, o painel também, talvez o serviço de e-mail também. Quando você adiciona containers Docker e processos workers, 2 GB de RAM perdem o fôlego.

Se o banco de dados estiver no mesmo VPS, o modelo adiciona uma sobrecarga de RAM. O tamanho do banco é dividido por 20; o resultado é limitado a um mínimo de 1 GB e um máximo de 8 GB. Por exemplo, mesmo para um banco de 5 GB, separa-se 1 GB de RAM. Para um banco de 30 GB, a sobrecarga fica em torno de 1.5 GB. No lado da CPU, adicionam-se 0.5 vCPU para o banco de dados.

Esses valores não são um cálculo de tuning de banco de dados. Se os índices estão ruins, as consultas são longas ou há locks de tabela, 0.5 vCPU não é suficiente. Mas, para um planejamento inicial, é melhor do que tratar o banco como “custo zero”.

Se o Redis/object cache estiver no mesmo VPS, adiciona-se 0.5 GB à RAM. O Redis trabalha em memória; quando você esquece isso, vê lentidões estranhas em servidores pequenos. Ele foi criado para melhorar o desempenho do cache, sim, mas ele próprio também exige RAM.

O painel de controle tem três níveis: nenhum, painel leve, painel completo tipo cPanel/Plesk. O painel leve adiciona 0.3 GB à RAM e 0.15 vCPU à CPU. O painel completo adiciona 1 GB à RAM e 0.3 vCPU à CPU. Instalar sistemas tipo cPanel ou Plesk em um VPS de 1 GB de RAM e depois esperar desempenho da aplicação não é uma boa ideia. O painel traz comodidade; você paga com recursos.

O número de workers/filas tem impacto direto. Para cada worker, adicionam-se 0.5 GB de RAM e 0.5 vCPU. Pode parecer um pouco alto, mas faz sentido se os trabalhos em segundo plano forem sérios. Processamento de imagens, geração de relatórios, busca de dados em APIs externas, esvaziamento de fila de e-mail, tarefas pós-pagamento... Se o worker não fica ocioso, ele consome recursos.

Se o serviço de e-mail roda no mesmo VPS, adicionam-se 0.5 GB de RAM e 0.3 vCPU. Deixando os recursos de lado, o serviço de e-mail também é trabalhoso operacionalmente. DNS, SPF, DKIM, DMARC, spam, fila, entregabilidade. Este cálculo enxerga apenas a parcela de recursos; não calcula a dor de cabeça.

Para uso de Docker/container, adicionam-se 0.5 GB de RAM e 0.2 vCPU. O Docker traz organização, mas não é de graça. Se o limite de memória, o comportamento de swap e a parcela de CPU do Docker não forem configurados corretamente, um container pode sufocar a máquina inteira. “Fizemos container, estamos tranquilos” nem sempre é a frase certa.

A essência do cálculo de CPU é esta: pega-se o maior valor entre a CPU base e a necessidade de CPU do tráfego, somam-se as cargas de CPU dos serviços, aplica-se o coeficiente de ambiente e a margem de crescimento. Na RAM, soma-se a RAM base com a RAM dos serviços, e novamente aplicam-se ambiente e margem de crescimento. Depois, o resultado é arredondado para os degraus práticos de pacote: em CPU, 1, 2, 4, 6, 8, 12, 16, 24, 32, 64; em RAM, 1, 2, 4, 8, 16, 32, 64, 128 GB.

Não existe mundo de frações. Se a necessidade de RAM deu 5.3 GB, olha-se para 8 GB. Se deu 3.1 vCPU, 4 vCPU faz sentido. Em ambiente de produção, fazer cálculo milimétrico aproxima você da parede a qualquer pequena oscilação.

No disco, o peso real às vezes está no que não se vê

Só porque a pasta do código é pequena, acha-se que a necessidade de disco é pequena. Esse é um erro de cálculo que vemos muito. A aplicação tem 3 GB, a mídia tem 10 GB; e dizem “20 GB de disco é suficiente”. Depois vêm logs, banco de dados, backup local, arquivos do sistema, imagens de container e arquivos temporários.

O cálculo de disco é feito com os arquivos da aplicação, mídia/upload, tamanho do banco de dados, log diário, dias de retenção de log e cópia de backup local. Se o banco de dados não estiver no mesmo VPS, ele não entra no cálculo de disco. Se estiver no mesmo VPS, entra.

Primeiro, forma-se o subtotal do disco: arquivos da aplicação + arquivos de mídia + banco de dados (se estiver no mesmo VPS) + log diário × dias de retenção. Depois, o número de cópias de backup local é considerado. Um backup local, grosso modo, duplica o conjunto de dados. Em seguida, adicionam-se 15 GB de parcela do sistema, aplica-se uma margem de segurança de 20%, e adiciona-se também a margem de crescimento. O resultado é arredondado para faixas de 10 GB, com um mínimo recomendado de 20 GB.

Não subestime os 15 GB de parcela do sistema. Sistema operacional, pacotes, resíduos de atualização, arquivos temporários, logs de serviços, imagens Docker e arquivos temporários do banco de dados ocupam espaço daí. Em produção, o disco não é apenas a sua pasta de uploads.

Os logs também são traiçoeiros. 0.5 GB de log por dia e 14 dias de retenção dão 7 GB. 2 GB de log por dia e 30 dias de retenção dão 60 GB. Crescem em silêncio. O disco passa de 80%, depois 90%, e então, durante um deploy, aquele erro famoso: no space left on device.

O backup local também exige atenção. Manter backup no mesmo disco não é garantia total em um cenário de desastre; se o disco se for, o backup vai junto. Mas, para uma recuperação rápida, uma cópia local pode ajudar. O modelo inclui isso no cálculo de recursos. Decisões como backup remoto, armazenamento de objetos e servidor de backup separado devem ser planejadas à parte.

No teste de produção WordPress, com 5 GB de arquivos da aplicação, 10 GB de mídia, 5 GB de banco de dados, 0.5 GB de log diário, 14 dias de retenção, 1 backup local e margem de crescimento de 30%, o disco recomendado é de 90 GB. À primeira vista, parece muito. Mas, somando log, backup, parcela do sistema e margem de segurança, não é exagero; é, antes, prudência.

No lado do e-commerce, o negócio cresce: 10 GB de arquivos da aplicação, 80 GB de mídia, 30 GB de banco de dados, 2 GB de log diário, 30 dias de retenção, 1 backup local e margem de crescimento de 50%. O disco resultante é de 480 GB. Se imagens de produtos, dados de pedidos, logs e backups estão na mesma máquina, esse resultado não surpreende.

Economizar demais no disco é um mau hábito. Se faltar CPU, você vê lentidão. Se faltar RAM, o swap começa. Se o disco encher, os serviços às vezes quebram de um jeito muito mais severo: o banco de dados não consegue gravar, o log não é criado, o arquivo de sessão não abre, o deploy fica pela metade. Pior: o erro nem sempre se explica com clareza.

Transformando o resultado em pacote

A saída tem quatro valores principais: CPU, RAM, disco e tráfego mensal. Não os coloque todos no mesmo balaio. Cada um mostra um limite diferente.

CPU é poder de processamento instantâneo. Requisição PHP, resposta de API Node.js, consulta ao banco de dados, tarefa de worker, processo pós-pagamento... Tudo isso toca a CPU. Quando o tráfego aumenta, a CPU pode aumentar; o cache pode reduzir isso, mas não apaga por completo.

RAM é o espaço dos serviços em execução. MySQL, Redis, PHP-FPM, processos Node.js, painel, containers Docker, serviço de e-mail, workers. Quando a RAM diminui, o sistema pode cair em swap. Ele até parece funcionar, mas fica pesado. Em aplicações dinâmicas, essa diferença é percebida rapidamente.

Disco é o armazenamento persistente. Arquivos da aplicação, mídia, banco de dados, logs, backups e arquivos do sistema dependem dele. No cálculo de disco, é preciso pensar não no tamanho atual, mas no acúmulo de alguns meses à frente.

Tráfego mensal é a transferência de dados. CDN, cache e otimização de páginas reduzem. A política de tráfego do provedor também deve ser verificada: existe cota? Há cobrança por excesso? Há redução de velocidade? O cálculo informa a necessidade em GB; não informa a condição comercial do provedor.

Neste modelo, os valores brutos são arredondados para os degraus práticos de pacote. Se a necessidade bruta é de 3.4 vCPU, recomenda-se 4 vCPU. Se a necessidade de RAM é de 9 GB, pode-se subir para o nível de 16 GB. O disco também é completado para faixas de 10 GB. Esse arredondamento às vezes faz o resultado parecer maior do que é, mas pacotes de VPS também não são vendidos com frações.

E tem mais: 4 vCPU pode não se comportar como 4 vCPU em todos os provedores. Geração da CPU, estrutura compartilhada/dedicada, camada de virtualização, tipo de disco, qualidade de rede, máquinas vizinhas — tudo isso faz diferença. Nos documentos de seleção de planos de provedores como a DigitalOcean, a distinção entre CPU compartilhada e dedicada não é destacada à toa.

Portanto, este cálculo deve ser visto como uma verificação técnica antes de apertar o botão de compra. Se você já tem um sistema, coloque-o lado a lado com métricas reais: gráfico de CPU, uso de RAM, ocupação de disco, saída de rede, consultas lentas, erros 5xx, tempo de espera na fila. Se você está montando um sistema novo, experimente alguns cenários.

O que acontece sem cache? Quando você escolhe CDN, quanto o tráfego cai? Ao separar o banco de dados do mesmo VPS, a RAM alivia? Quando o número de workers vai de 0 para 4, para onde vai a CPU? Quanto a cópia de backup local aumenta o disco?

A escolha do pacote às vezes sai das respostas a essas perguntas, e não de uma única linha de resultado.

Se eu fosse você, olharia especialmente para três valores: o fator de pico, se o banco de dados está no mesmo VPS e a cópia de backup local. Porque, na vida real, são eles que mais bagunçam o cálculo. O tráfego se acumula em uma hora, o MySQL no mesmo servidor come mais RAM do que o esperado e os backups enchem o disco. Depois, todo mundo culpa o pacote de CPU.

Às vezes a culpa não é da CPU.