Redis vs Memcached vs Varnish for PHP page caching on a VPS with limited I/O

By Kevin Marcondes · Published on Oct 28, 2026 · 8 min read

Which cache should you use for PHP pages when your VPS struggles with disk I/O? This comparison evaluates Redis, Memcached and Varnish with a focus on environments with limited I/O. You’ll see architecture, resource usage, invalidation patterns, pros and cons, and when each option makes the most sense for full‑page and fragment caching in PHP.

Scenario: VPS with limited I/O — what changes the decision

Limited I/O means high iowait, long read/write queues and unpredictable latency. In this situation, caches that avoid touching the disk and prioritize RAM are preferable. For PHP there are two levels to consider: full‑page cache (the entire HTTP response) and fragment/object cache (rendered parts, query results, etc.). The higher the RAM hit ratio, the less pressure on PHP‑FPM and the database.

Choosing a cache here requires balancing latency, memory footprint, invalidation and how much I/O the caching component itself generates. In general, favor memory‑first strategies with appropriate TTLs and predictable invalidation.

If the VPS also has limited RAM, size the cache conservatively and monitor closely. Consider how to choose the right VPS size.

The three options in one minute

A quick overview of each tool’s role in this context:

• Redis: an in‑memory store with rich data structures. It can persist to disk, but for pure caching it’s common to disable persistence to avoid I/O.
• Memcached: a simple, fast in‑memory key‑value store, always volatile. Zero persistence and low overhead.
• Varnish: an HTTP reverse proxy for full‑page caching. It can use memory (malloc) and supports policies like grace/stale to smooth traffic spikes.

Architecture: where each one sits in the request flow

Varnish sits in front of PHP at the HTTP layer. It receives the request, checks for a cached object and, on a hit, responds without touching your application. For TLS, the common practice is to terminate HTTPS in a proxy and forward HTTP to Varnish. Compare reverse proxy options for multiple containers in Traefik vs Nginx: Reverse Proxy for Docker.

Redis and Memcached run as services accessed by PHP. Your application writes and reads keys, setting TTLs and keys that map to pages, fragments or query results.

For robust orchestrations, align health checks between the app and the cache. See best practices for PHP health checks & readiness.

Performance and resource usage with restricted I/O

Redis: for caching only, disable persistence (RDB/AOF) and set maxmemory with an appropriate eviction policy. That way you effectively eliminate disk writes. With persistence enabled, periodic I/O will occur.

Memcached: always memory‑only with no persistence. It’s predictable in terms of I/O (near zero) and works well for key‑value workloads with short TTLs.

Varnish: choose memory storage (malloc) to avoid disk writes. Configure cache sizes in line with available RAM. A short microcache can reduce backend load during spikes without consuming excessive memory.

Monitor latency, hit rate and saturation. A practical path is to set up Prometheus and Grafana to track cache effects and system I/O.

Features for full‑page caching and invalidation

Varnish provides VCL for advanced rules, PURGE/BAN for invalidation, ESI for composing blocks and grace/stale‑while‑revalidate policies. It’s excellent for public pages and microcaching for a few seconds.

Redis supports tagging and granular invalidation using structures like sets, and it can run Lua scripts. It integrates well with PHP via the Redis extension: https://www.php.net/manual/en/book.redis.php.

Memcached is simple and fast but lacks native tags; you typically implement namespaced keys with a version prefix. It integrates with PHP via the Memcached extension: https://www.php.net/manual/en/book.memcached.php.

• If you need fine‑grained control with tags and dependencies, Redis usually makes that easier.
• If your goal is simply latency reduction with straightforward keys and short TTLs, Memcached is sufficient.
• For caching the entire HTTP response and microcache scenarios, Varnish is typically more effective.

Operation, security and complexity

Varnish requires learning VCL, designing invalidation policies and protecting PURGE/BAN endpoints. In TLS setups there’s usually a proxy handling certificates.

Redis needs memory tuning, eviction policy configuration, authentication and network isolation. If persistence is enabled, plan for backups and anticipate I/O. Cluster and Sentinel add operational complexity.

Memcached is minimalist. For high availability you rely on client‑side sharding or consistent hashing. Operations are generally simpler with fewer knobs to adjust.

Regardless of choice, implement readiness checks and circuit breakers in the app for cache failures.

When to choose each one (practical guidance)

Decision paths for VPSes with limited I/O:

• Choose Varnish when your focus is full‑page caching of public content, high hit rates and using a microcache to smooth spikes, with memory storage.
• Choose Redis when you need tags, granular invalidation, fragment caching or coordination across multiple PHP instances. For pure cache use, disable persistence to avoid I/O.
• Choose Memcached when you want simplicity and zero persistence for keys with short TTLs, and you don’t need advanced data structures.
• Combine Varnish + Redis/Memcached: Varnish handles whole pages while a store keeps fragments, sessions (if acceptable) and locks.
• For user sessions, evaluate the impact of data loss: if unacceptable, consider Redis with careful persistence settings; if acceptable, Memcached with short TTLs may suffice.

Essential comparison table

A summary of the most relevant criteria for VPSes with limited I/O:

Frequently asked questions

Does Varnish work with HTTPS?

Yes, but the common approach is to terminate TLS in a proxy in front of Varnish and forward plain HTTP to it. This simplifies certificate management and lets Varnish focus on caching. You can also keep the app behind a proxy that handles HTTPS and routing.

Is Redis without persistence safe to use as a cache?

For pure caching, yes. Disabling persistence reduces I/O and accepts that keys are lost on restart. Set maxmemory and an appropriate eviction policy. If you can’t tolerate data loss (e.g., critical sessions), evaluate persistence carefully because it reintroduces disk I/O.

Memcached or Redis for PHP user sessions?

Memcached is simple and fast but volatile; session loss on failures may impact users. Redis can persist sessions with RDB/AOF, but that adds I/O. On an I/O‑constrained VPS, prefer short TTLs and weigh availability versus disk writes.

Can I use Varnish and Redis together?

Yes. Varnish serves entire pages with microcache and grace policies while Redis stores fragments, query results and locks. This combination reduces load on PHP‑FPM and the database while keeping granular invalidation in the application layer.

What TTL should I use for microcaching PHP pages?

It depends on content and tolerance for staleness. Microcache values are typically a few seconds to smooth spikes and protect the backend. Start small, monitor hit rate and latency, and adjust based on real traffic patterns.

How do I monitor whether caching is helping?

Track hit rate, P95/P99 latency and memory usage. Also monitor iowait and disk queues. Combine metrics from the proxy, cache and PHP‑FPM into dashboards and alerts to detect regressions quickly.

See also

• ZFS vs LVM+LUKS on VPS for Databases — snapshots, performance and post-failure recovery
• Practical comparison — Nginx Unit vs PHP‑FPM vs RoadRunner for PHP monoliths in containers — latency, throughput & memory
• ZFS vs Btrfs for Snapshots, Replication and Incremental Retention on VPS with Docker — Practical Pros and Cons
• Flyway vs Liquibase vs Sqitch: database versioning for PHP/Laravel projects