Nginx static file cache or Varnish in front?

Events happening in the community are now at Drupal community events on www.drupal.org.
gateway69's picture

I have used varnish quite a bit on my LAMP stacks and this deff helps quite a bit out for static files to serve up and keeps the load off of apache.

I hear good things about nginx static file caching so is their a need to put varnish up a head of it?

Comments

Varnish can be configured to

lotyrin's picture

Varnish can be configured to intelligently cache even dynamic resources with advanced features like ESI, allowing certain kinds of resources to cache even for logged-in users. The configuration language is both flexible and fast. Varnish is app/language agnostic, so can run on separate machines from your app (or even another data center) to add more memory/network resources to your infrastructure.

Nginx can be configured to have many of the same properties, but Varnish gains simplicity and power from being designed specifically for this task. Also, in the Drupal community at least, Varnish has a large and supportive user base.

Nginx might be an excellent app server, but Varnish is basically THE memory-mapped reverse caching proxy.

Well

perusio's picture

I guess if you dig the kind of mess that VCL is or if you prefer to make your stack more complex, hence more fragile, or if you prefer to front your event driven server with a threaded proxy then go for Varnish. Nobody will get fired for choosing Varnish. But I digress...

But then absolute statements with THE aside, you should choose whichever you feel more comfortable with. There are plenty of extremely large Nginx based sites that use Nginx for everything, from HTTP serving, to reverse proxying, to layer 7 load balancing, to caching.

Evaluate and make your decision. Don't be influenced by over the top statements.

PHP?

lotyrin's picture

I don't see how separation of concerns potentially complicates things any more than it potentially simplifies them. Any solution can suffer from incompetency, if your Ops aren't as familiar with VCL as with Nginx, then obviously you'd feel that way. I could say something about hammers and nails, but Nginx is admittedly a really nice sort of hammer which makes it reasonable to use it for more solutions than the average hammer.

We are talking about Drupal, or at least fairly traditional *GI PHP here right? It hardly matters that Nginx is evented when it's in front of an application that builds its state up (by making tens of SQL queries) then discards it for each request. I don't see why Varnish's concurrency model matters for similar reasons.

If someone's asking me for a solution for avoiding costly synchronous requests to a *GI application, I feel like recommending them anything more complicated than using their package manager to install Varnish then using a application-community-provided VCL would be leading them into too deep of water to start.

Sure, "[t]here are plenty of extremely large Nginx based sites that use Nginx for everything" but not everyone has their Ops budget.

Agreed

perusio's picture

that the limiting factor when accessing non-cached content will be PHP and not the proxy you have in front. Be it threaded or evented.

But when accessing cached content things are different. The real benefit comes not only on being evented, which is a theoretical advantage, but also from that fact that Nginx has baked in a couple of facilities to control abuse and mitigate attacks. Remember that the two main poles of development are Russia and China, both hotbeds of malicious network activity, at least from our western biased point of view.

Not considering that you really need to make your setup a good deal more complex if you have SSL traffic. Nginx makes an excellent SSL terminator/offloader. Other option is relying on something like stud when using Varnish.

So in the end things even out. Although there's bound to be much more Varnish trained (dev)ops, using it can in the end cost you more in terms of hours on the job.

There's good community support for Nginx and Drupal, in fact, although in some aspects we're lagging (e.g., wordpress.com runs solely on Nginx) on others we're leading. AFAIK after the Nginx mailing lists, this group here is the most helpful place for sharing and learning Nginx stuff.

SSL Nginx in front of Varnish

cthshabel's picture

Perusio,

Thanks so much for your contributions to the Drual Nginx group. I'm using a variation of your config on github. I have been going back and forth with this article and a few others you commented on. You mention using SSL traffic with varnish is more complex (using stud when using Varnish). I know it seems unorthodox to go Nginx (SSL termination) --> Varnish --> Nginx, but there shouldn't be a problem doing this, right?

I am just about ready to drop Varnish, I have been really close for several weeks now. The large amount of Drupal docs and discussions supporting Varnish make this a tough decision. I think using Nginx for everything would be "simpler", yes; however, my knowledge is limited to get Nginx configured correctly (which is what this convo is about, hence why I figured i'd comment too).

I am currently facing cache issues with Varnish getting ESI configured correctly (definitely an extra moving part to learn); whereas, I could sink my time into learning more about SSI for Nginx and along the way become more familiar with what Nginx cache has to offer. After a lot of reading, Nginx seems to be a realistic contender performance-wise, but less documentation that Varnish makes me weary. I'll just have to dive in and hope that I float if I can't swim!

Thanks again for everything. LOVE Nginx btw it is blazing fast.

High performance

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: