7 ms·

1) Nginx is a fully fledged Web server and has some performance penalty compared to Varnish. The latter is lightening fast. 2) Nginx is no match for Varnish's

by jjoe 16y ago

1) Nginx is a fully fledged Web server and has some performance penalty compared to Varnish. The latter is lightening fast. 2) Nginx is no match for Varnish's VCL for header/cache manipulation Regards

hphp 16y ago
1- yes but at the very highest loads 2- you don't need that much manip. for simple load balancing. 3- can you backup your claims with reference(s)?
- jjoe 16y ago
  1 - not necessarily 2 - it depends on app complexity. Most people that read Y need it. 3 - Benchmarks? sure :) http://www.unixy.net/apache-vs-litespeed http://www.unixy.net/apache-vs-litespeed
  - zepolen 16y ago
    What does an Apache v Litespeed benchmark have to do with anything?
    - jjoe 16y ago
      The above post proposed that Varnish is not needed because Nginx could handle the task well with the best performance. But Nginx is a bit slower than Varnish. It's been shown in benchmarks that Litespeed is a bit faster than Nginx. By inductive reasoning to show that Varnish is faster than Nginx, I posted a link to show that Varnish is faster than Litespeed, which in turn is faster than Nginx. So Varnish is faster than Nginx. Let me know if you have any question/comment. Regards
      - zepolen 16y ago
        My question is how you manage to stay in business with such flawed 'reasonings'. That benchmark in particular is so full of crap that people will become dumber after reading it.
        jjoe 16y ago
        I'm not going to respond to your personal attacks; just the factual content of you post(s). I understand that you perceived my posting of the benchmark link to be inappropriate and I agree with you to an extent. It remains to say that the link represents my proof within the context of the conversation chain from earlier. You seem to be a long-term contributor here and I'm sure it's appreciated. I would be interested if you addressed the flaws or issues with the benchmark results. I do make mistakes just like anybody but own up to them at the end. Let me know if you have any question and I'll be happy to discuss. Regards Joe
        zepolen 16y ago
        Flaws with the benchmark: 1. Misrepresentation The title says 'Apache vs Litespeed', when in reality it is 'Varnish vs Litespeed', Apache has nothing to do with this particular benchmark. 2. Questionable results Varnish serving 217.05 req/sec for a static page at 100 concurrency level? Something is seriously messed up in the setup; Varnish can easily handle thousands of req/s for something as simple as looking up a cache entry and returning a static file for 100 clients. Oh wait, 11177.99 [Kbytes/sec] - looks like you saturated the pipe, making it a test of how fast your network is, and nothing to do with Varnish. 3. Flawed benchmark testing procedure You can't expect a simple `ab -c 100 -n 10000` to provide any insight whatsoever towards the general handling of a server. The only thing obvious is that Litespeed has been saturated with 100 concurrent connections. If you're going to do a benchmark, you must post varying concurrency levels at least (along with exact setup configurations). Likewise, cpu and memory usage are just as important to providing valuable insight. 4. Comparing apples to oranges I'm not entirely sure what Litespeed is doing (eg. does it cache statically?) since you haven't specified it exactly, but considering that almost 70% of the requests failed and almost all requests after the first few had a different content length, I would assume that Litespeed is returning a dynamic request each time, whereas Varnish is returning a static file. I have no doubt in my mind that if you ran the same scenario (ie. Litespeed serving a static file as well) the results would be much different. 5. Irrelevant to the article benchmark Saying "But Nginx is a bit slower than Varnish", then linking to a terrible irrelevant benchmark and using circular logic (based on another completely crap Litespeed vs Nginx for serving php!? benchmark) to infer that Varnish is faster than nginx hurts my brain. I ran a really simple benchmark on Varnish 2.1.3 and nginx 0.8.49's proxy_cache directive on a single url; nginx is faster. However, what if we test a heavy config with a bunch of complicated rules? Varnish's VCL compiles straight to C and might give it the edge in those cases. What if we use test a million different urls and really test how each one handles their cache hit/miss procedures. How do they fare under real world scenarios where thousands of different clients on various connection speeds are connected? I know nginx is damn efficient memory wise when dealing with a load of keepalives. 6. Conclusion Good benchmarks are difficult.
fanf2 16y ago
What do you need a fully-fledged web server on the edge nodes for? Wouldn't it be better for varnish to proxy everything to the back end dynamic server directly, except for requests that need to use the local edge node nginx? The post describes a setup with two cacheing layers on each edge node, varnish cache in front of ngingx cache, which has got to be sub-optimal.
- jjoe 16y ago
  Nginx is used as a disk cache and varnish is used as a memory cache. So you're saying that why not scrap nginx and let varnish run the show on the edge nodes? That works just fine too. Keep in mind that the goal of the article is to build an affordable CDN based on VM edge nodes. Memory is still expensive on VMs (especially if you're going to be renting VMs in costly locations). So if you have say a 20GB static store that needs to be served, on a 2GB RAM VPS, Varnish will only be able to cache that much files and be forced to make round trips to the dynamic node on miss. Varnish does have "persistent" storage capabilities but from what I've read they're still experimental. Regards
polynomial 16y ago
Not sure why you're getting negged here; using nginx without Varnish, you're not going to get nearly the speed, and using Vanish on Apache just doesn't make a lot of sense. Not sure what you mean by "has some performance penalty compared to Varnish" however.
- jjoe 16y ago
  Nginx "has some performance penalty compared to Varnish" The performance penalty comes the number of system calls needed to complete the request. According to the Varnish arch docs, it's 18 syscalls (http://varnish-cache.org/wiki/ArchitectNotes http://varnish-cache.org/wiki/ArchitectNotes). Also, Varnish doesn't malloc for each new request/header. It mallocs once per workspace. Unfortunately there's no such thing as Nginx vs Varnish benchmarks because Varnish is just a cache (apple to orange comparison). Regards Joe
  - zepolen 16y ago
    Nginx has had an apples to apples proxy_cache directive since 0.7 which does the exact same job as Varnish (albeit lacking a few features yet). Also read my other reply to your comment: http://news.ycombinator.com/item?id=1593611 http://news.ycombinator.com/item?id=1593611 I suggest you take down that benchmark article, because it is flawed on too many levels.
    - jjoe 16y ago
      Header manip is very important if one needs to control caching. I'm not sure Nginx has this capability at such granular level. Varnish's VCL excels at this. As explained above, all info has been disclosed on the page in question. It's up to the reader to agree or disagree with the results. Let's face it, benchmarks are always going to be controversial and imperfect. One should always take the initiative to verify results by running their own tests. Regards Joe
      - zepolen 16y ago
        Nginx does have that capability on a much more granular level in fact. That benchmark was entirely useless for all the points I mentioned in the other post, but predominantly because you saturated your network on one of those tests, which meant the bottleneck was the network and not the webserver. All your counterpoints were ignorant/naive and just went to show me how much you don't understand what is going on. This wouldn't be a bad thing in itself, everyone has to start somewhere, but to think you do this for a living...

by jjoe 16y ago

hphp 16y ago

1- yes but at the very highest loads 2- you don't need that much manip. for simple load balancing. 3- can you backup your claims with reference(s)?

jjoe 16y ago
1 - not necessarily 2 - it depends on app complexity. Most people that read Y need it. 3 - Benchmarks? sure :) http://www.unixy.net/apache-vs-litespeed http://www.unixy.net/apache-vs-litespeed
- zepolen 16y ago
  What does an Apache v Litespeed benchmark have to do with anything?
  - jjoe 16y ago
    The above post proposed that Varnish is not needed because Nginx could handle the task well with the best performance. But Nginx is a bit slower than Varnish. It's been shown in benchmarks that Litespeed is a bit faster than Nginx. By inductive reasoning to show that Varnish is faster than Nginx, I posted a link to show that Varnish is faster than Litespeed, which in turn is faster than Nginx. So Varnish is faster than Nginx. Let me know if you have any question/comment. Regards
    - zepolen 16y ago
      My question is how you manage to stay in business with such flawed 'reasonings'. That benchmark in particular is so full of crap that people will become dumber after reading it.
      - jjoe 16y ago
        I'm not going to respond to your personal attacks; just the factual content of you post(s). I understand that you perceived my posting of the benchmark link to be inappropriate and I agree with you to an extent. It remains to say that the link represents my proof within the context of the conversation chain from earlier. You seem to be a long-term contributor here and I'm sure it's appreciated. I would be interested if you addressed the flaws or issues with the benchmark results. I do make mistakes just like anybody but own up to them at the end. Let me know if you have any question and I'll be happy to discuss. Regards Joe
        zepolen 16y ago
        Flaws with the benchmark: 1. Misrepresentation The title says 'Apache vs Litespeed', when in reality it is 'Varnish vs Litespeed', Apache has nothing to do with this particular benchmark. 2. Questionable results Varnish serving 217.05 req/sec for a static page at 100 concurrency level? Something is seriously messed up in the setup; Varnish can easily handle thousands of req/s for something as simple as looking up a cache entry and returning a static file for 100 clients. Oh wait, 11177.99 [Kbytes/sec] - looks like you saturated the pipe, making it a test of how fast your network is, and nothing to do with Varnish. 3. Flawed benchmark testing procedure You can't expect a simple `ab -c 100 -n 10000` to provide any insight whatsoever towards the general handling of a server. The only thing obvious is that Litespeed has been saturated with 100 concurrent connections. If you're going to do a benchmark, you must post varying concurrency levels at least (along with exact setup configurations). Likewise, cpu and memory usage are just as important to providing valuable insight. 4. Comparing apples to oranges I'm not entirely sure what Litespeed is doing (eg. does it cache statically?) since you haven't specified it exactly, but considering that almost 70% of the requests failed and almost all requests after the first few had a different content length, I would assume that Litespeed is returning a dynamic request each time, whereas Varnish is returning a static file. I have no doubt in my mind that if you ran the same scenario (ie. Litespeed serving a static file as well) the results would be much different. 5. Irrelevant to the article benchmark Saying "But Nginx is a bit slower than Varnish", then linking to a terrible irrelevant benchmark and using circular logic (based on another completely crap Litespeed vs Nginx for serving php!? benchmark) to infer that Varnish is faster than nginx hurts my brain. I ran a really simple benchmark on Varnish 2.1.3 and nginx 0.8.49's proxy_cache directive on a single url; nginx is faster. However, what if we test a heavy config with a bunch of complicated rules? Varnish's VCL compiles straight to C and might give it the edge in those cases. What if we use test a million different urls and really test how each one handles their cache hit/miss procedures. How do they fare under real world scenarios where thousands of different clients on various connection speeds are connected? I know nginx is damn efficient memory wise when dealing with a load of keepalives. 6. Conclusion Good benchmarks are difficult.

fanf2 16y ago

What do you need a fully-fledged web server on the edge nodes for? Wouldn't it be better for varnish to proxy everything to the back end dynamic server directly, except for requests that need to use the local edge node nginx? The post describes a setup with two cacheing layers on each edge node, varnish cache in front of ngingx cache, which has got to be sub-optimal.

jjoe 16y ago
Nginx is used as a disk cache and varnish is used as a memory cache. So you're saying that why not scrap nginx and let varnish run the show on the edge nodes? That works just fine too. Keep in mind that the goal of the article is to build an affordable CDN based on VM edge nodes. Memory is still expensive on VMs (especially if you're going to be renting VMs in costly locations). So if you have say a 20GB static store that needs to be served, on a 2GB RAM VPS, Varnish will only be able to cache that much files and be forced to make round trips to the dynamic node on miss. Varnish does have "persistent" storage capabilities but from what I've read they're still experimental. Regards

polynomial 16y ago

Not sure why you're getting negged here; using nginx without Varnish, you're not going to get nearly the speed, and using Vanish on Apache just doesn't make a lot of sense. Not sure what you mean by "has some performance penalty compared to Varnish" however.

jjoe 16y ago
Nginx "has some performance penalty compared to Varnish" The performance penalty comes the number of system calls needed to complete the request. According to the Varnish arch docs, it's 18 syscalls (http://varnish-cache.org/wiki/ArchitectNotes http://varnish-cache.org/wiki/ArchitectNotes). Also, Varnish doesn't malloc for each new request/header. It mallocs once per workspace. Unfortunately there's no such thing as Nginx vs Varnish benchmarks because Varnish is just a cache (apple to orange comparison). Regards Joe
- zepolen 16y ago
  Nginx has had an apples to apples proxy_cache directive since 0.7 which does the exact same job as Varnish (albeit lacking a few features yet). Also read my other reply to your comment: http://news.ycombinator.com/item?id=1593611 http://news.ycombinator.com/item?id=1593611 I suggest you take down that benchmark article, because it is flawed on too many levels.
  - jjoe 16y ago
    Header manip is very important if one needs to control caching. I'm not sure Nginx has this capability at such granular level. Varnish's VCL excels at this. As explained above, all info has been disclosed on the page in question. It's up to the reader to agree or disagree with the results. Let's face it, benchmarks are always going to be controversial and imperfect. One should always take the initiative to verify results by running their own tests. Regards Joe
    - zepolen 16y ago
      Nginx does have that capability on a much more granular level in fact. That benchmark was entirely useless for all the points I mentioned in the other post, but predominantly because you saturated your network on one of those tests, which meant the bottleneck was the network and not the webserver. All your counterpoints were ignorant/naive and just went to show me how much you don't understand what is going on. This wouldn't be a bad thing in itself, everyone has to start somewhere, but to think you do this for a living...