Exemplo real: VPS 4 cores x tráfego WordPress

VPS 4 cores WordPress. Vamos analisar um exemplo real de VPS com 4 cores e 12 GB de RAM rodando WordPress. Vou detalhar tráfego, limites e otimizações possíveis, baseado em cenários práticos.

Em muitos casos, problemas de performance em WordPress hospedado em VPS não acontecem de forma constante. Lentidão, erros 502 ou picos de latência podem aparecer apenas em determinados momentos de tráfego. Nesses cenários, é essencial investigar o ambiente corretamente antes de fazer mudanças na infraestrutura. No guia sobre como diagnosticar problemas intermitentes capturando evidências no servidor, mostramos uma abordagem prática para investigar esse tipo de situação.

Cenário do VPS

• CPU: 4 cores (ex.: 4×2.5 GHz)
• RAM: 12 GB
• Storage: SSD NVMe 200 GB
• Webserver: Apache + Nginx (proxy reverso)
• PHP-FPM: 8 workers
• Banco: MariaDB 11.3
• Sites: 4 WordPress

1. Tráfego suportado

O tráfego depende de diversos fatores: cache, tema, plugins, otimizações de PHP-FPM/MySQL e tipo de conteúdo. Aqui estão números práticos:

Observação: Cache (WP Rocket, LiteSpeed Cache ou Varnish) é crítico. Sem cache, mesmo 4 cores podem servir apenas 500–800 visitantes simultâneos antes de notar lentidão.

2. Limites de CPU/RAM

• PHP-FPM: Cada worker consome ~70–100 MB (temas/plugins medianos). Com 4 cores, 8–12 workers é ideal.
• MariaDB: Para WP médio, 2–4 GB de RAM dedicados é suficiente, mas queries pesadas exigem tuning.
• Nginx/Apache: Para 4 cores, manter MaxRequestWorkers ~50–60 no Apache + proxy via Nginx é ideal.

Quando um servidor começa a apresentar lentidão apenas em horários específicos ou sob determinados níveis de tráfego, o problema pode ser mais complexo do que simplesmente falta de recursos. Nessas situações, é fundamental aplicar técnicas de investigação de problemas intermitentes em servidores Linux, coletando métricas e logs antes de qualquer alteração.

3. Exemplo de otimização real

# PHP-FPM (www.conf)
pm = dynamic
pm.max_children = 12
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
memory_limit = 256M

# MySQL/MariaDB (/etc/my.cnf)
innodb_buffer_pool_size = 6G   # ~50% RAM
max_connections = 100
query_cache_type = 0
query_cache_size = 0

# Nginx proxy buffer
proxy_buffers 16 16k;
proxy_buffer_size 32k;

4. Observações práticas

• Sites WordPress leves com cache: 4 cores + 12 GB RAM podem atender até 30k visitas/dia com picos de ~5k/h sem sofrer lentidão.
• Sites WooCommerce ou com plugins pesados: picos de 1.5–2k/h já podem sobrecarregar PHP-FPM sem tuning.
• Monitoramento crítico: CPU, load average e swaps. Mesmo com CPU ociosa, se MySQL não estiver otimizado, o site sente lentidão.

Vamos montar uma tabela prática e realista para um VPS 4 cores / 12 GB RAM rodando WordPress, mostrando tráfego máximo seguro, incluindo caches, tipo de site e picos.

Tráfego WordPress em VPS 4C/12GB – Tabela prática

Notas práticas

1. Cache é crítico:
   • Sem cache, 4 cores servem 500–800 visitantes simultâneos antes de lentidão.
   • Com cache, a CPU praticamente não é o gargalo, mas MySQL e RAM ainda contam.
2. Picos vs média diária:
   • Média diária não significa segurança em picos. PHP-FPM precisa estar ajustado.
3. PHP-FPM recomendação real:
   • pm = dynamic
   • pm.max_children = 12
   • memory_limit = 256M
4. MariaDB / MySQL tuning:
   • innodb_buffer_pool_size = 6G (~50% RAM)
   • max_connections = 100
   • query_cache = 0 (WordPress não usa mais)
5. Monitoramento:
   • CPU: load average < 4
   • RAM: evitar swap
   • MySQL: queries > 0.5s precisam tuning

Antes de escalar um VPS ou migrar para um servidor maior, é importante confirmar se o problema realmente está relacionado à capacidade da infraestrutura. Seguir uma metodologia adequada de captura de evidências em problemas intermitentes de servidores ajuda a evitar diagnósticos incorretos.

FAQ

Veja Mais:

Problemas Intermitentes em Servidores: Como Capturar Evidências Reais
Firewall no Linux com firewalld e nftables: Guia Prático para Produção
ZRAM e ZSWAP: impactos reais em produção
Redis vs Memcached: qual cache usar em servidores Linux