11–20 of 24 posts
More context on why Varnish is superior to Squid: http://varnish-cache.org/wiki/ArchitectNotes
To give some context, this describes how Varnish combines mmapping with a nice memory partitioning scheme to get free caching from the OS, instead of fighting the OS' tendency to cache and managing it yourself.
Earlier quoted context omitted.
This might be most popular setup right now, but I wouldn't consider it the best practice. Why in the world would you use both nginx and varnish?
Because until 0.7 nginx lacked a caching system, and so it made sense to use both. Now it doesn't.
I still love Nginx though :-)
Agreed, nginx+varnish (optionally on top of an existing apache setup) seems to be best practice right now for heavy traffic sites.
This might be most popular setup right now, but I wouldn't consider it the best practice. Why in the world would you use both nginx and varnish?
It's also likely[1] faster and more well behaved under high loads, simply because it has been around for much longer and seen more tuning in large deployments.
[1] Disclaimer: I haven't benchmarked them against one another, that's merely my common-sense assessment.
Agreed, varnish is awesome, we use it on a home-brew CDN and it has been a fantastic experience so far. Also, the guy that wrote it (Poul Henning-Kamp) is very responsive when it comes to answering questions or fixing issues, they have an IRC channel at #varnish on irc.linpro.no. Definitely a piece of software worth looking in to when your website gets bigger.
Earlier quoted context omitted.
I don't think it's required, but, really, why wouldn't you be running varnish? It's just amazing.
Because it doesn't add anything useful to the mix - nginx's cache works just fine.
Earlier quoted context omitted.
This might be most popular setup right now, but I wouldn't consider it the best practice. Why in the world would you use both nginx and varnish?
Because varnish is more flexible (VCL) and more time tested. It's also likely [1] faster and more well behaved under high loads, simply because it has been around for much longer and seen more tuning in large deployments. [1] Disclaimer: I haven't benchmarked them against one another, that's merely my common-sense assessment.
Earlier quoted context omitted.
Because it doesn't add anything useful to the mix - nginx's cache works just fine.
Sure it does, it adds ESI (which is fantastic). It also keeps backend connections open rather can creating/destroying them for each request. Varnish does restarts nicely too, we have requests that get passed on to another group of servers if the backend returns errors. It's really a very nice way of brokering http requests.
Earlier quoted context omitted.
Because varnish is more flexible (VCL) and more time tested. It's also likely [1] faster and more well behaved under high loads, simply because it has been around for much longer and seen more tuning in large deployments. [1] Disclaimer: I haven't benchmarked them against one another, that's merely my common-sense assessment.
How is VCL more flexible?
More context on why Varnish is superior to Squid: http://varnish-cache.org/wiki/ArchitectNotes
Earlier quoted context omitted.
How is VCL more flexible?
This is a question that interests me as a Varnish user with a several-hundred-line VCL. We exclude certain URLs from caching altogether, drop certain cookies but not others, drop certain querystring params but not others, cache separate versions of the same page for mobile and non-mobile browsers, do limited caching behind basic auth, purge certain pages from cache when a post gets published, etc. VCL isn't the most…
You can get fancy[1] by writing your own modules or by building on top of helpers like ngx_devel_kit, but it gets messy very quick.
Implementing complex rules inside the config file is possible to a degree - but an utter nightmare. The syntax is extremely limited and the semantics are hard to predict (order of execution).
So, what nginx is lacking is a proper scripting interface with full control over the request pipeline. ngx_lua and ngx_v8 are in the works but not production-ready, yet.
Personally I'd go as far and say the entire config file should simply be ripped out and replaced with a scripting language.
[1] http://agentzh.org/misc/slides/nginx-conf-scripting/nginx-co... (press cursor right to walk through slides)