Caching is the cheapest performance upgrade most servers ever get: serve the answer you already computed instead of computing it again. A well-placed cache can cut response times from hundreds of milliseconds to single digits and keep a small VPS alive under real traffic.

Here are five caching tools that cover the different layers of a Linux stack — from full web pages down to individual database queries.

1. Redis — the in-memory everything store

Redis keeps data in RAM, which makes reads absurdly fast. People call it a cache, but it's really a data structure server: strings, hashes, lists, sorted sets, with optional persistence.

Typical uses: caching database query results, session storage, rate limiting, and job queues.

sudo apt install redis-server redis-cli SET page:home "<html>...</html>" EX 300 # cache for 5 minutes redis-cli GET page:home

If your application hits the same expensive query fifty times a second, putting Redis in front of it is often a one-evening fix.

2. Memcached — simple and still excellent

Memcached does less than Redis — pure key-value caching, no fancy structures, no persistence — and that's exactly why some teams prefer it. It's tiny, multithreaded, and perfect for caching rendered fragments or database rows.

sudo apt install memcached # listens on 127.0.0.1:11211 by default

Choose Redis when you need data structures or persistence; choose Memcached when you just want a fast, boring cache that never surprises you.

3. Varnish — full-page HTTP acceleration

Varnish sits in front of your web server and caches entire HTTP responses. Instead of Nginx/PHP rebuilding a page for every visitor, Varnish serves the cached copy and your backend barely gets touched.

It's the tool behind many high-traffic news sites, configured with its own language (VCL) so you can decide exactly what gets cached, for how long, and which cookies to ignore.

sudo apt install varnish # default: listens on 6081, talks to your backend on 8080

For a mostly-public site (blogs, docs, marketing pages), Varnish can multiply your capacity several times over.

4. Nginx FastCGI/proxy cache — caching without new software

If you already run Nginx, you already have a capable cache. A few lines cache PHP or upstream responses:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=PHPCACHE:100m inactive=60m; server { location ~ \.php$ { fastcgi_cache PHPCACHE; fastcgi_cache_valid 200 10m; fastcgi_pass unix:/run/php/php-fpm.sock; include snippets/fastcgi-php.conf; } }

No extra daemon, no extra moving parts. For small-to-medium sites this is often all the caching you need — our Nginx reverse proxy guide covers the surrounding setup.

5. Squid — forward proxy caching

Squid is a different animal: it caches outbound traffic for a whole network. Schools, offices, and ISPs use it so that when fifty people download the same update, it crosses the internet link once.

It's not something you put in front of your website — it's something your users' traffic passes through. For homelabs and offices with metered or slow connections, it still earns its keep.

Which one do you actually need?

  • App-level query/session caching → Redis (or Memcached for simplicity)
  • Whole pages, high traffic → Varnish
  • Whole pages, small stack → Nginx's built-in cache
  • Shared outbound bandwidth → Squid

Measure first, cache second: find the slow layer (database? PHP? external API?), then cache that layer. Caching the wrong tier just makes the fast parts faster while the bottleneck stays put.