We currently serve most of our Rails and LAMP apps over Apache and Apache passenger, but we're considering adding Nginx or Varnish as a reverse proxy to reduce the load on our servers somewhat.

I'm aware that you can use Varnish and Nginx together, but given that there's investment of time in learning how both work, and where possible we want to keep the number of 'moving parts' in our infrastructure as low as possible, I'm trying to work out what the advantages and disadvantages are between using:

  • nginx by itself as a the reverse reverse proxy/cache
  • varnish alone as the reverse proxy/cache
  • nginx and varnish together

I understand nginx is known to be extremely fast, and it's gaining prominence as a full blown http server as it gets more popular, so I can see the argument for investing some time in learning how this server works, but Varnish is still an unknown to me.

Why would I use Varnish if nCache is now in Nginx?



Do you anticipate using Edge Side Includes (ESI)? If so, the Nginx ESI module is broken and has some open bugs. If you use Varnish, output isn't compressed, so you're somewhat stuck using Nginx to do compression of ESI enabled pages. While I work with Python frameworks, Rails is similar.

With your current setup, you could do something like:

Nginx -> Apache -> Passenger -> Rails Varnish -> Apache -> Passenger -> Rails

Both would drop in front of your existing system. With Nginx, you could also give it direct access to the static files and allow it to serve those without having to proxy through Apache. Using the Location directive, you can slice off portions of your webspace and prevent that from having to go through the proxy.

However, if you wanted to move completely to Nginx, your infrastructure becomes:

nginx -> passenger -> rails (nginx -> uwsgi -> python)

If you add Varnish, you end up with:

varnish -> nginx -> passenger -> rails

unless you use ESI, in which case you end up with:

nginx -> varnish -> nginx -> passenger -> rails

At some point, removing Varnish from the mix becomes quite intriguing. However, recent Varnish releases are still faster than Nginx's caching and you have a lot of control over how you can cache. While both Nginx and Varnish give you quite a bit of control, Varnish's VCL allows you to write C code to do things that neither does out of the box, without touching the daemon's source code. Whether that is useful to you is up to you.

Since you are using Apache currently, I would be more inclined to put Varnish in front unless you are going to migrate to Nginx and remove Apache completely. Varnish in your case is more of a drop-in solution. If you decide that you're going to use ESI in the future, you would need to run both.

  • 1
    Thanks - as we haven't switched to nginx just yet, your answer is making varnish look like a more compelling solution in the short run. In the long run nginx, looks to be a really capable replacement for Apache, but right now - I don't think it's too wise to make that jump for now, as we have to support a number of java and perl apps too, I'm expecting all kinds of unexpected pain in the transition... – Chris Adams Jul 17 '10 at 8:49
  • @karmawhore would you like to update something, maybe the changes in both nginx and varnish, along these years. – beginer Nov 30 '14 at 10:11

Here is a comparison test of Varnish, Nginx (the raising star), Apache Traffic Server (another proxy cache), G-WAN (an application server with C scripts) and Lighttpd (a real good wweb server):


Apache Traffic Server is an HTTP proxy and cache server created by Inktomi, and distributed as a commercial product before Inktomi was acquired by Yahoo.

Yahoo says that it uses TS in to serve more than 30 Billion objects per day. They also say that TS is a "product of literally hundreds of developer-years".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.