Disclaimer: I never used Varnish. So please do not treat this as Varnish v/s Nginx post. It will be wrong on my part to compare Nginx to something that I have never used.
Since we published WordPress-Nginx tutorials, we have been asked many times that why we haven’t posted anything about Varnish!
Here is my attempt to answer…
Short Answer: Using Varnish + Nginx is not worth *my* effort!
Long Answer…
Time-saving:
I never used Varnish. So I will have to spend some time learning Varnish. Apart from this, Varnish will increase one more package on Nginx + PHP + MySQL + APC/Memcache stack we commonly use. That means if something goes wrong, we will need to debug Varnish also apart from other packages!
So not only in learning but I will have to spend time in maintenance on ongoing basis.
Static-content:
Nginx can handle static files itself pretty fast. On larges sites, people generally use CDN to host static files (images, videos, js, css, etc).
Varnish is surely useful when used with Apache. If Apache has mod_php enabled, Apache performance significantly drops for static-file requests.
Load-Balancer, Reverse-Proxy:
Again, Nginx does this for me! In a client-setup, we have a micro Amazon EC2 instance running nginx as load-balancer in front of range of PHP, mysql.
Beauty of Nginx is that it can directly talk to other Nginx and PHP directly. It can read from memcache directly! So it works really well for us in multi-machine environment.
In second part of our WordPress-Nginx Tutorial Series, I will write in depth about load-balancing, reverse-proxy etc. (You can subscribe here for updates.)
Benchmarks…
I am not fond of benchmarks. Still, if Varnish + Nginx gives 5-10% performance improvement but cost in days to learn and hours every month in ongoing maintenance, I will prefer to leave that 5-10% of performance gain.
That being said I find this Varnish/Nginx benchmark quite good!
Finally…
My point is… rather than learning multiple tools partially, I will dig deeper into Nginx. I will master it to the point that it can cater to all our needs! 
That’s it from my side! You can prove me wrong using comment-form below! 
It sounds like you have done exactly what I am planning to do!
I also think varnish is overkill and want to use nginx for everything. What plugins are you using? Seems to me that the nginx cache plugins and memcache plugin do not work together. The memcache plugin assumes that something else fills memcache right?
I know nginx pretty well so if you can just sketch the solution here before you post the follow up article I would really appreciate it.
We use APC Cache for database & object cache via W3 Total Cache plugin. For conditional purging of page-cache we are using Nginx Helper. Apart from that we use Nginx’s fastcgi-cache only to generate page-cache.
For memcache, which I will recommend only in environment where a site is hosted across multiple machines, I think you can use Nginx’s built-in memcache module with a WordPress plugin which will “fill-up” cache. There are many WordPress plugins which can store cached pages in memcache but I haven’t tested them yet.
Since I am tmpfs for fastcgi_cache storage location, it as fast as memory-based caching. (tmpfs is created in RAM)
The irony of your post is that you likely spent more time writing it then it would take to get a basic Varnish setup and actually test it …
@Joshua
Its not one time cost. It may take like 30-mins to figure out how to get Varnish working! But what about ongoing debugging and maintenance?
We have so many use-cases here for Nginx’s fastcgi_cache that Varnish docs will fail to cover.
On a site with geo-targeting enabled, for every wordpress post/page, we store 8-different version of pages in fastcgi_cache and then serve correct version based on user-ip/preference so that backend PHP/mysql can rest in piece. Then see this use-case.
We also use Nginx as a load-balancer. Nginx can talk to PHP on different machine itself when cache is missed! It simplifies deployment and ongoing management because we can move with one app i.e. Nginx alone.
We have more than 100-sites/apps on Nginx (for us and our customers) and most of them have complex nginx config.
Only feature, I like of Varnish is ESI – https://www.varnish-cache.org/trac/wiki/ESIfeatures but I am exploring few things in Nginx to take care of this. Also, once a page is completely cached, ESI won’t come into picture unless we need to regenerate page i.e. cache-flush. In that case also, parts like sidebar are present in RAM (in APC, via Object-Cache from W3 Total Cache plugin).
Unless Varnish is 5-times faster (or can handle same traffic in 5 times less hardware), we are better with Nginx. In fact going by trend, one can move from Varnish to http://gwan.com/benchmark!
The point is – either you can test every new thing every day or master something for a while and get the best out of it!
Maybe I should rephrase then. I felt like this post should have been titled ‘The great things we like about Nginx’ rather than its current title. I came here from Google looking for interesting performance reasons against Varnish but found workflow reasons against it. As a tutorial, discouraging readers from trying new things because ‘they are hard and time consuming’ is a bit antithetical to learning.
I completely support your decision to use Nginx in your workflow and not Varnish. It makes plenty of sense to choose a tool that works really really well.
I personally have found Varnish to be a good tool to use in combination with Nginx. You have a point, it took some time to learn. But my site loads pretty fast and I’m really happy with it.
Thanks for the reply. Also, G-WAN seems bogus: http://martijn.vanderlee.com/?p=396
@Joshua
This article was intended for my readers who were asking when I will cover Varnish in our WordPress-Nginx series – http://rtcamp.com/series/wordpress-nginx-tutorials/
You can see my disclaimers and reason behind posting at the start.
I am blogging from 2006 and I have maintained a line that I will never post negative reviews. If I cannot encourage somebody, I must not discourage them either.
In fact, that is the reason why I added clear disclaimer in the beginning as I was bit uncomfortable while writing this but this made my life easier.
When readers or clients ask for Varnish and when I say NO, link to this article save me form writing long answer to their next question – WHY?
For records, I referenced benchmark here – http://todsul.com/nginx-varnish , which I found convincing as per my intuition.
Based on my experience, benchmarks in general can be “tailored”. For example, most articles I see on Internet talk about performance of static-file handling between Nginx and Varnish.
I am not sure about Varnish but in Nginx, if you run a benchmark again by turning off access_log for static files, you will get a decent speed-up. It could be around 2x. Because when access_log are on, for every FILE READ, Nginx is performing FILE WRITE by writing to access logs. Of-course DISK WRITES can be buffered (and buffering will again give us different results!)
We deal with WordPress sites everyday where most plugins are developed by amateurs. When we run them on big sites MySQL slowlog is full of unoptimized queries. By optimising mysql queries, adding MySQL query-cache & object-cache, minifying/combining CSS/JS (almost every plugin adds 1 CSS and 1 JS file to output HTML), adding CDN we get the maximum performance benefit.
My goal these days is to reduce cache-miss penalty. Serving static files or cached webpages isn’t much of a concern as I am not dealing with a site with million hits per day.
Anyway, thanks for that link about G-WAN. I am not sure about truth behind G-WAN’s performance but you can see debate about “benchmarks” in comments there.
Personally, I am driven by intuition and not by benchmarks. In fact, I haven’t done much benchmarking even though I spent considerable time in last 4-years on Nginx.
To me I must be comfortable with technologies I use. Today, I am very much comfortable with Nginx.
That being said, I won’t deny the fact that some day I may leave Nginx for something better in future. I just “feel” Varnish is not better “enough” for my work, atleast today.
I have actually installed Vanish in front of Nginx in a production site running Drupal with “boost” module.
After some time of using it, I realized it added no benefit. I made some tests about it, you can read them here:
http://www.garron.me/en/go2linux/nginx-varnish-vs-nginx-alone-compared.html
and here: http://www.garron.me/en/linux/apache-vs-nginx-php-fpm-varnish-apc-wordpress-performance.html
But another thing I have learned is that you can configure Apache with fastcgi, and it will work almost as good as Nginx. More here:
http://www.garron.me/en/blog/wordpress-apache-ubuntu-mpm-worker-php-fpm.html
Sorry for so many links, I am not trying to spam here, I really think they are relevant to the topic of this posts.
I am not sure how you ran benchmarks or how your application is configured.
Nginx is always better than Apache. Also, PHP5-FPM is better than fastcgi.
Are you using Drupal or WordPress? If you are not getting better performance with Nginx + PHP5-FPM, as compared to Apache + fastcgi, then that simply means there is some misconfiguration.
Nginx is always faster than Apache.
But if you really need Apache, or really want Apache (.htacces for example). And I know you can replace .htacces with Nginx rules, but htacces is so convenient sometimes.
Well in that case, using Apache + PHP-FPM instead of Apache+mod_PHP is almost as good as Nginx. Specially for the non PHP content.
For the PHP content, you can improve with cache techniques.
Nginx micro-cache as reverse proxy
Varnish
WP-Super cache for WP
Boost for Drupal
But once again Nginx is always faster than Apache.
In my limited experience with Nginx, I fail to understand what extra benefits you get from putting Varnish in front of it, except for additional obfuscation — on a set of cloud instances, you could, for instance, run several Nginxes on separate instances in a cloud-based, private network, and just have Varnish being publicly accessible. So hackers would only be able to attack Varnish — which is not a webserver and, as such, cannot be easily tricked to run commands… — but not go beyond that. So even a misconfigured Nginx would not present such a big security risk.
Other than that, it would like expecting having a benefit of having Squid in front of Varnish, or Varnish in front of Squid — both do the same (but Squid is bloated and tough to configure). There would be no benefit in that. Running Nginx in front of Apache is another story, since Nginx could, in that case, do everything that Apache is not good at: delivering static files superquickly, handle a distributed cache, and so forth — while leaving Apache to handle PHP, which it does marginally better than PHP-FPM (on servers with plenty of memory!). That would make sense.
But putting a fast static serving application in front of another fast static server application…? I also fail to understand the benefit in terms of raw performance. Both would be doing basically the same thing. Except for security concerns, I don’t understand the point of using Varnish with Nginx.
Nothing against Varnish, btw! It’s the salvation for current Apache/IIS users who have no option but to stick with Apache/IIS. At least they can benefit from Varnish’s superfast distributed caching mechanism…
@Gwyneth
Agree with all points except:
I guess you are comparing mod_php (Apache specific) with PHP-FPM. For a PHP request, I am not sure weather “Apache + mod_php” will be faster than “Apache + PHP-FPM” but for non-PHP requests “Apache + mod_php” will be very slow as compared to using Apache with fastcgi or PHP-FPM.
PHP-FPM offeres too many advantages to ignore, and since it can be used directly with Nginx, I do not see any reason to bring Apache into picture.
Please correct me if I missed a use-case (except some legacy codes which makes use of Apache’s feature heavily and cannot leave without Apache!)