Revisado em 12/11/2026: removidos relatos de clientes e números sem comprovação; o texto agora apresenta critérios de diagnóstico e decisão.
Uma VPS lenta no pico não prova que falta servidor. O limite pode estar na CPU, memória, armazenamento, configuração da aplicação, banco ou serviço externo. Antes de ampliar, identifique qual parte está esperando, qual recurso está saturado e se o componente pode aproveitar recursos adicionais.
Este guia é para quem mantém uma aplicação em VPS ou infraestrutura própria e precisa decidir como atender uma campanha, lançamento ou aumento de demanda. Não apresenta caso de cliente, estimativa de vendas perdidas nem percentual de economia.
Registre o incidente antes de escolher uma solução
Compare sinais do mesmo intervalo: horário, URLs afetadas, latência, erros e volume de requisições. Registre também deploys, backups e tarefas agendadas. Tráfego e lentidão ocorrerem juntos é uma pista, não prova da causa.
| Sinal observado | O que investigar | O que não concluir sozinho |
|---|---|---|
| CPU alta e resposta degradada | Processo responsável, trabalho por requisição e tarefas concorrentes | Que aumentar réplicas na mesma máquina vai resolver |
| Aplicação em fila com CPU baixa | Limites de concorrência, banco, disco e integrações | Que a máquina está saudável porque a CPU está livre |
| Swap ativo e pressão de memória | Consumo por processo, limites e tarefas no mesmo host | Que basta abrir mais processos |
| Conexões do banco no limite | Pools, consultas e duração das conexões | Que mais réplicas da aplicação aumentam a capacidade do banco |
| Checkout lento e catálogo rápido | Serviços de frete, pagamento, ERP e caminhos não cacheados | Que toda a loja precisa de mais CPU |
O guia de monitoramento de VPS explica como guardar evidência. Para o caminho de compra, veja o diagnóstico de checkout lento.
Separe o trabalho evitável da capacidade realmente necessária
Cache, consultas, configuração de processos e tarefas concorrentes podem alterar o trabalho que cada visita gera. Essas opções têm esforço e limites; não são uma promessa de custo zero ou de que todo problema se resolve sem ampliar.
Se o sistema consegue atender a carga com uma configuração melhor, ampliar antes de medir pode esconder o problema. Se os recursos efetivamente necessários superam a base, adiar toda expansão até uma otimização perfeita também pode ser uma escolha ruim. Compare caminhos com prazo, custo, risco e critério de aceite.
Para aplicações PHP, o dimensionamento de pm.max_children ajuda a separar processos disponíveis de memória. Para banco, consulte o guia de gargalo MySQL.
Quais alternativas comparar?
Otimizar a aplicação ou a operação
Faz sentido quando há trabalho desnecessário, consulta lenta, concorrência mal configurada ou tarefa pesada disputando recursos. O resultado precisa ser verificado antes e depois, com carga comparável.
Ampliar a VPS ou a infraestrutura base
Pode ser a escolha mais simples quando a demanda maior é frequente, quando o serviço não distribui bem ou quando o esforço da arquitetura híbrida não se justifica. Compare desempenho e disponibilidade, não só os recursos anunciados no plano.
Adicionar capacidade temporária
Merece avaliação quando o pico é limitado, o serviço é replicável e as dependências suportam a concorrência adicional. Preparar essa expansão envolve rede, imagens, estado e operação; não se resume a ligar outra máquina.
Migrar para outra plataforma
Uma plataforma gerenciada ou outro orquestrador pode atender a requisitos que o ambiente atual não cobre. Migrar não é automaticamente mais caro, mais barato ou mais escalável. Inclua os serviços gerenciados utilizados, o esforço de mudança e a capacidade de operar a solução.
O comparativo de custo completo ajuda a explicitar as hipóteses. Evite comparar uma VPS única com uma arquitetura redundante como se oferecessem o mesmo serviço.
Réplicas e servidores são decisões diferentes
No Docker Swarm, mudar a quantidade de réplicas não cria CPU ou memória adicional. Novos nós oferecem recursos; a aplicação ainda precisa conseguir agendar tarefas e atender por eles.
O Swarm não redistribui automaticamente todas as tarefas existentes apenas pela entrada de um nó, segundo o guia de administração do Docker. Uma política de expansão precisa coordenar esses movimentos e conferir o atendimento real.
Veja o guia de autoscaling em VPS para os comandos de inspeção e os cuidados de agendamento.
Antes de uma campanha, valide um cenário representativo
Use ambiente próprio autorizado ou janela combinada com o responsável pela operação. O teste deve representar os caminhos relevantes: ler catálogo é diferente de autenticar, adicionar ao carrinho ou concluir compra em sandbox.
Defina antes quais latências, taxas de erro e sinais de recurso exigem interromper o teste. Registre ambiente, versões, cache, gerador de carga e limitações. Não converta automaticamente usuários virtuais em visitantes do analytics.
O roteiro de teste de carga inclui um exemplo inicial de catálogo em k6 e explica o que ele não mede.
Onde o SwarmBurst pode entrar
O SwarmBurst é um agente para Docker Swarm instalado no ambiente do cliente. No fluxo atual, a VPS continua como base e nós temporários AWS podem executar réplicas do serviço escolhido durante picos.
A aplicação precisa ser compatível. Sessões e uploads exclusivos do disco local, banco saturado e dependências lentas não são resolvidos automaticamente por novas máquinas. O guia de estado em múltiplos servidores ajuda a avaliar esse ponto.
A implantação é assistida. Inclui verificar rede, permissões, imagens, serviço escalado, limites operacionais e como reduzir a capacidade depois. Não há promessa de instalação em poucos minutos, disponibilidade sem interrupção, capacidade ilimitada ou economia antecipada.
Após encerrar instâncias, é necessário conferir recursos associados. A documentação de ciclo de vida da EC2 distingue a cobrança de execução da cobrança de outros recursos. O controle de orçamento do agente não representa garantia absoluta da fatura da conta AWS.
O que levar para a avaliação
Reúna arquitetura, serviço afetado, métricas do pico, dependências e critérios de desempenho. Leve também o custo atual e as alternativas que está considerando. Não envie credenciais ou dados pessoais de clientes pelo contato inicial.
O resultado pode ser otimizar, ampliar a VPS ou preparar capacidade temporária. O objetivo da avaliação é escolher um caminho compatível com o problema observado, sem pressupor que o SwarmBurst seja a resposta para todo cenário.
