Comparativo: Redis vs Memcached vs Varnish para cache de páginas PHP em VPS com I/O limitado

Por Kevin Marcondes · Publicado em 28/10/2026 · 7 min de leitura

Plato brilhante de disco rígido com braço atuador visível — Close-up de HDD que ilustra gargalos de I/O em servidores VPS. Foto: FreePhotosART / Pixabay

Qual cache escolher para páginas PHP quando a sua VPS sofre com I/O de disco? Neste comparativo, analisamos Redis, Memcached e Varnish focando em ambientes com I/O limitado. Você verá arquitetura, consumo de recursos, invalidação, prós e contras e quando cada opção faz mais sentido para cache de página e fragmentos em PHP.

Cenário: VPS com I/O limitado — o que muda na decisão

I/O limitado significa alto iowait, filas de escrita/leitura e latências imprevisíveis. Nessa condição, caches que evitam toques no disco e priorizam RAM ganham. Para PHP, há dois níveis: full‑page cache (a resposta HTTP completa) e cache de fragmentos/objetos (partes renderizadas, queries, etc.). Quanto maior o hit ratio na RAM, menor a pressão em PHP‑FPM e no banco.

Escolher um cache aqui exige equilibrar: latência, footprint de memória, invalidação e quanto de I/O o componente gera. Em geral, prefira estratégias memory‑first, com TTLs adequados e invalidação previsível.

Se a VPS também tem pouca RAM, dimensione o cache com cuidado e monitore. Veja como escolher o tamanho da VPS.

As três opções em 1 minuto

Uma visão rápida do papel de cada ferramenta neste contexto:

Redis: armazenador em memória com estruturas ricas. Pode ter persistência, mas para cache puro, usa‑se sem persistência para evitar I/O.
Memcached: key‑value em memória, simples e rápido, sempre volátil. Zero persistência, baixa sobrecarga.
Varnish: reverse proxy HTTP para full‑page cache. Pode usar memória (malloc) e aplicar políticas como grace/stale para suavizar picos.

Arquitetura: onde cada um atua no fluxo da requisição

Varnish atua antes do PHP, na camada HTTP. Ele recebe a requisição, decide se há um objeto em cache e, em caso positivo, responde sem tocar no seu app. Para TLS, costuma‑se terminar HTTPS em um proxy e repassar HTTP para o Varnish. Compare opções de proxy em reverse proxy para múltiplos containers.

Redis e Memcached vivem como serviços acessados pelo PHP. Você grava/consulta chaves no código, escolhendo TTLs e chaves que representem páginas, fragmentos ou resultados de consultas.

Para operações robustas em orquestrações, alinhe verificações de saúde do app e do cache. Veja boas práticas de health checks e readiness no PHP.

Desempenho e consumo de recursos com I/O restrito

Redis: para cache puro, desative persistência (RDB/AOF) e defina maxmemory com política de eviction apropriada. Assim, praticamente elimina escrita em disco. Com persistência ligada, haverá I/O periódico.

Memcached: sempre em memória e sem persistência. É previsível em I/O (próximo de zero) e simples para workloads key‑value com TTLs curtos.

Varnish: escolha storage em memória (malloc) para evitar escrita em disco. Configure tamanhos compatíveis com RAM disponível. Microcache pode reduzir carga de picos sem inflar memória.

Monitore latência, taxa de acertos e saturação. Um caminho prático é configurar Prometheus e Grafana para acompanhar o efeito do cache.

Funcionalidades para full‑page cache e invalidação

Varnish: oferece VCL para regras avançadas, PURGE/BAN para invalidar, ESI para compor blocos e políticas grace/stale‑while‑revalidate. Excelente para páginas públicas e microcache de poucos segundos.

Redis: permite tags e invalidação granular com estruturas como sets, além de scripts Lua. Integra bem com frameworks PHP via drivers da extensão Redis do PHP.

Memcached: simples e rápido. Sem tags nativas; usa‑se namespacing por versão de chave. Integração direta via extensão Memcached do PHP.

Se você precisa de controle fino por tags e dependências, Redis tende a facilitar.
Se o objetivo é somente reduzir latência com chaves simples e TTL curto, Memcached é suficiente.
Para cache da resposta HTTP completa e microcache, Varnish costuma ser mais eficaz.

Operação, segurança e complexidade

Varnish exige aprender VCL, pensar em políticas de invalidação e proteger endpoints de PURGE/BAN. Em setups com TLS, normalmente há um proxy na frente gerindo certificados.

Redis requer definir memória, política de eviction, autenticação e isolamento de rede. Com persistência ativada, planeje backups e I/O. Cluster e Sentinel aumentam a complexidade.

Memcached é minimalista. Para alta disponibilidade, depende de sharding/consistent hashing no cliente. Operação tende a ser mais simples, com menos alavancas para ajustar.

Independente da escolha, alinhe readiness e circuit‑breakers no app para falhas do cache.

Quando escolher cada um (decisões práticas)

Caminhos de escolha em VPS com I/O limitado:

Escolha Varnish se o foco é full‑page cache de conteúdo público, alto hit ratio e microcache para suavizar picos, usando storage em memória.
Escolha Redis se precisa de tags, invalidação granular, cache de fragmentos e coordenação entre múltiplas instâncias PHP. Para cache puro, sem persistência para evitar I/O.
Escolha Memcached se quer simplicidade e zero persistência para chaves com TTL curto, sem necessidade de estruturas avançadas.
Combine Varnish + Redis/Memcached: Varnish para páginas e um store para fragmentos, sessões não críticas e locks.
Para sessões de usuários, avalie impacto de perda: se inaceitável, Redis com persistência leve; se aceitável, Memcached com TTL curto.

Tabela comparativa essencial

Resumo dos critérios mais relevantes para VPS com I/O limitado:

Ferramenta	Camada	Bom para full‑page cache PHP	Impacto de I/O	Persistência	Invalidação/Tags	Complexidade de operação	Observações
Redis	Key‑value em memória (acessado pelo app)	Indireto (via app salvando HTML)	Baixo sem persistência; com AOF/RDB há I/O	Opcional (RDB/AOF)	Alta (tags, scripts, estruturas)	Média (tuning de memória, segurança, cluster opcional)	Versátil; útil também para filas, locks e fragmentos
Memcached	Key‑value em memória (acessado pelo app)	Indireto (via app salvando HTML)	Praticamente zero I/O	Não possui	Baixa (namespacing simples)	Baixa (operação simples)	Ótimo para TTLs curtos e chaves simples
Varnish	Reverse proxy HTTP (frente ao app)	Sim, nativo e eficiente	Baixo usando malloc; file storage pode tocar disco	Não (cache volátil)	Média/Alta (VCL, PURGE/BAN, ESI)	Média/Alta (requer VCL e integração)	Excelente para microcache e tráfego público

Perguntas frequentes

Varnish funciona com HTTPS?

Sim, mas a prática comum é terminar TLS em um proxy na frente e repassar HTTP para o Varnish. Isso simplifica certificados e permite que o Varnish foque no cache. Você também pode manter o app atrás de um proxy que gerencie HTTPS e roteamento.

Redis sem persistência é seguro para cache?

Para cache puro, sim. Sem persistência você reduz I/O e aceita perder chaves em reinícios. Defina maxmemory e uma política de eviction adequada. Se não puder perder dados (ex.: sessões críticas), avalie persistência com cautela, pois ela reintroduz I/O.

Memcached ou Redis para sessões de usuários no PHP?

Memcached é simples e rápido, porém volátil; a perda de sessões em falhas pode afetar usuários. Redis pode persistir sessões com RDB/AOF, mas isso adiciona I/O. Em VPS com I/O limitado, use TTLs curtos e pese disponibilidade versus escrita em disco.

Posso usar Varnish e Redis juntos?

Sim. Varnish atende páginas inteiras com microcache e políticas grace, enquanto Redis armazena fragmentos, resultados de consultas e locks. Essa combinação reduz carga em PHP‑FPM e banco, mantendo invalidação granular no nível da aplicação.

Qual TTL usar para microcache de páginas PHP?

Depende do conteúdo e da tolerância a desatualização. Microcache geralmente usa poucos segundos para suavizar picos e proteger o backend. Comece pequeno, monitore hit ratio e latência e ajuste conforme o comportamento real do tráfego.

Como monitorar se o cache está ajudando?

Acompanhe taxa de acertos, latência P95/P99 e uso de memória. Observe também iowait e filas de disco. Integre métricas do proxy, do cache e do PHP‑FPM em dashboards e alertas para identificar regressões rapidamente.

Quer definir a estratégia de cache certa para sua VPS?

Avalie, prototipe e valide Varnish, Redis e Memcached com métricas e rollback prontos. Vamos discutir seu cenário e mapear o caminho mais seguro.

Falar sobre arquitetura de cache