5 ms·

why varnish when nginx

maggit 10y ago
I use both in concert in several installations. Varnish is so blindingly fast that it is a great addition in virtually any stack :)
- zepolen 10y ago
  Fast and unstable at high concurrency.
  - acdha 10y ago
    Do you have any details about that?
    - zepolen 10y ago
      Most of the problems stem from the thread pool - and most of my personal observations come from using both in production. Up to a certain high load, Varnish works well, then all hell breaks loose - Nginx in comparison was much more stable and used less resources, had a higher max throughput, and when it hit the max - (assuming it filenode limit was high enough) would still work..just slowly. Varnish just died.
      - jimjag 10y ago
        There is this sad idea that "threads are bad" and that event is the cat's pajamas. But even nginx admits that there are situations where threads make sense, hence their semi-recent addition to adding them. I encourage people to read http://capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf http://capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf. Yeah, it's old, but so is the 10k Concurrency paper which is still touted as the reason why people should use nginx instead of anything else. Threads will only get better.
      - olavgg 10y ago
        Sounds like you had a gigantic malloc and used too much memory and let Linux kill it. http://stackoverflow.com/questions/16693677/why-isnt-varnish-taking-into-account-the-malloc-limit http://stackoverflow.com/questions/16693677/why-isnt-varnish... If you really need a large malloc, I highly recommend running Varnish on FreeBSD instead of Linux as the Linux kernels VM system is horrible when memory is overcommitted.
      - acdha 10y ago
        Interesting - curious about what the actual failures were as I've never seen failures like that with fairly large Varnish caches. nginx wasn't an option for us until they made it handle the HTTP Vary header correctly so I don't have recent comparative experience with it as a cache.
ibotty 10y ago
It's way more configurable. Different class.
olavgg 10y ago
In most setups, Varnish will perform a lot better. 10x better performance should be expected for any high traffic site. Varnish is a lot easier to configure if you have some complexity, for example if you want to cache the same page but for different languages that is sent from the browser. There is also another alternative, Apache Traffic Server. In the end, it may be Nginx, Apache Traffic Server which are the right tools for your problem. None of them solves every caching problem.
- jimjag 10y ago
  Apache Traffic Server is the bee's-knees. ++1!
jimjag 10y ago
There is this concept, especially in enterprise level architecture which is similar to a separation of concerns; basically that you use tools to solve a particular need. Sure, one could get by using the built-in caching of nginx or Apache httpd (version 2.4.x, which is just as performant as nginx), but when the cache becomes a bottleneck, and it WILL at some point when using a "does everything solution", you need something that simply does caching and does it WELL. Varnish will simply beat the pants off of nginx and httpd in head-to-head caching tests. Plus, the level of configurability in Varnish is again much, much better than what exists in nginx or httpd. It seems kind of nasty to say this, but nginx isn't the be all and end all. Now, yeah, you could say I'm biased, but this is because instead of being swayed by marketing, PR and FUD, I instead am swayed by real world scenarios. nginx is very, very good, but it is no longer heads-and-shoulders above httpd or anything else really. It is weird, and wrong, to take every other tool which does a part of what nginx does and immediately want to criticize it or say "nginx does that too! What do we need Foo for?!" When doing architecture, pick the right tools for the right job. And most of the time that means picking a caching layer, a TLS termination layer, dynamic content, Authn&Authz layer, etc...

I use both in concert in several installations. Varnish is so blindingly fast that it is a great addition in virtually any stack :)

zepolen 10y ago
Fast and unstable at high concurrency.
- acdha 10y ago
  Do you have any details about that?
  - zepolen 10y ago
    Most of the problems stem from the thread pool - and most of my personal observations come from using both in production. Up to a certain high load, Varnish works well, then all hell breaks loose - Nginx in comparison was much more stable and used less resources, had a higher max throughput, and when it hit the max - (assuming it filenode limit was high enough) would still work..just slowly. Varnish just died.
    - jimjag 10y ago
      There is this sad idea that "threads are bad" and that event is the cat's pajamas. But even nginx admits that there are situations where threads make sense, hence their semi-recent addition to adding them. I encourage people to read http://capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf http://capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf. Yeah, it's old, but so is the 10k Concurrency paper which is still touted as the reason why people should use nginx instead of anything else. Threads will only get better.
    - olavgg 10y ago
      Sounds like you had a gigantic malloc and used too much memory and let Linux kill it. http://stackoverflow.com/questions/16693677/why-isnt-varnish-taking-into-account-the-malloc-limit http://stackoverflow.com/questions/16693677/why-isnt-varnish... If you really need a large malloc, I highly recommend running Varnish on FreeBSD instead of Linux as the Linux kernels VM system is horrible when memory is overcommitted.
    - acdha 10y ago
      Interesting - curious about what the actual failures were as I've never seen failures like that with fairly large Varnish caches. nginx wasn't an option for us until they made it handle the HTTP Vary header correctly so I don't have recent comparative experience with it as a cache.

ibotty 10y ago

It's way more configurable. Different class.

olavgg 10y ago

In most setups, Varnish will perform a lot better. 10x better performance should be expected for any high traffic site. Varnish is a lot easier to configure if you have some complexity, for example if you want to cache the same page but for different languages that is sent from the browser. There is also another alternative, Apache Traffic Server. In the end, it may be Nginx, Apache Traffic Server which are the right tools for your problem. None of them solves every caching problem.

jimjag 10y ago
Apache Traffic Server is the bee's-knees. ++1!

jimjag 10y ago

There is this concept, especially in enterprise level architecture which is similar to a separation of concerns; basically that you use tools to solve a particular need. Sure, one could get by using the built-in caching of nginx or Apache httpd (version 2.4.x, which is just as performant as nginx), but when the cache becomes a bottleneck, and it WILL at some point when using a "does everything solution", you need something that simply does caching and does it WELL. Varnish will simply beat the pants off of nginx and httpd in head-to-head caching tests. Plus, the level of configurability in Varnish is again much, much better than what exists in nginx or httpd. It seems kind of nasty to say this, but nginx isn't the be all and end all. Now, yeah, you could say I'm biased, but this is because instead of being swayed by marketing, PR and FUD, I instead am swayed by real world scenarios. nginx is very, very good, but it is no longer heads-and-shoulders above httpd or anything else really. It is weird, and wrong, to take every other tool which does a part of what nginx does and immediately want to criticize it or say "nginx does that too! What do we need Foo for?!" When doing architecture, pick the right tools for the right job. And most of the time that means picking a caching layer, a TLS termination layer, dynamic content, Authn&Authz layer, etc...