Web-server – Fail-over caching reverse proxy

I don't think that there is a way to explicitly invalidate cached items, but here is an example of how to do the rest. Update: As mentioned by Piotr in another answer, there is a cache purge module that you can use. You can also force a refresh of a cached item using nginx's proxy_cache_bypass - see Cherian's answer for more information.

In this configuration, items that aren't cached will be retrieved from example.net and stored. The cached versions will be served up to future clients until they are no longer valid (60 minutes).

Your Cache-Control and Expires HTTP headers will be honored, so if you want to explicitly set an expiration date, you can do that by setting the correct headers in whatever you are proxying to.

There are lots of parameters that you can tune - see the nginx Proxy module documentation for more information about all of this including details on the meaning of the different settings/parameters: http://nginx.org/r/proxy_cache_path

http {
  proxy_cache_path  /var/www/cache levels=1:2 keys_zone=my-cache:8m max_size=1000m inactive=600m;
  proxy_temp_path /var/www/cache/tmp; 


  server {
    location / {
      proxy_pass http://example.net;
      proxy_cache my-cache;
      proxy_cache_valid  200 302  60m;
      proxy_cache_valid  404      1m;
    }
  }
}

If you already have the software installed and running, I suggest that you measure the CPU performance on that server. Even if you have other stuff running on the same server, it may not matter. If the CPU load is 33% or less of what that server is capable of, then it is realistic to put it in a virtual machine running on similar or more powerful hardware.

Any potential performance degradation from going virtual depends on the other virtual machines which share the same hardware. Ideally, if you have a heavy CPU load, you should only install virtual machines with a light load on the same server. And the same probably goes for network I/O and disk I/O. But don't jump to conslusions. Measure the load on the CPU, the network and the disks, then make the decision based on those measurements.

Leave yourself some headroom when sizing out your virtual machine server to allow for growth in the load of ALL virtual machines that will go onto it.

Since Varnish is built around serving cached data from memory, by nature it will be light on the disk load, which means that it is a good candidate for running in a virtual machine. But do make sure that the physical server has the ability to expand the RAM, for instance a quad core machine with 16gigs of RAM max, will provide a nice Varnish server with 4G of RAM for the Varnish VM. And if the Varnish VM needs to grow, you can do a simple RAM upgrade rather than migrating to another physical server.