Student here.
Why is Nginx more popular than G-WAN?
I saw the benchmarks for G-WAN earlier this week (http://gwan.com/benchmark) and am curious why most people would choose nginx over the performance that G-WAN provides?
Why is Nginx more popular than G-WAN?
I saw the benchmarks for G-WAN earlier this week (http://gwan.com/benchmark) and am curious why most people would choose nginx over the performance that G-WAN provides?
Also, it seems that a lot of the "performance" in G-WAN is thanks to its microcaching feature. When it's under high concurrent load, it caches requests for about 1 second. I suppose it's useful on public cacheable responses and useful in benchmarks, but does this really count as "faster" in the sense that G-WAN is a faster system overall? I don't know.
That being said, G-WAN has many interesting aspects indeed.
This. This.
I find more articles about why NOT to use G-WAN more than anything.
What about this?
http://nbonvin.wordpress.com/2011/03/24/serving-small-static...
It doesn't really help that the author gives off some mild "losethos" style vibes (the rantings about open source software, the weird "buy an encrypted archive of the source" thing, etc.)
I'm sure it is very impressive in some very limited circumstances, but it really isn't something that I want to get close to. I can't trust people so.. untrusting.
1) G-WAN is closed source. This means you're tied to their paid support for fixes and improvements. Web servers are pretty critical pieces of infrastructure that are not replaced easily (if you're doing large deployments, custom config, etc.) and so having this risk is huge. 2) Documentation, configurability, support for well-tested integration with various application servers. For example, Nginx supports uWSGI out-of-box. The G-WAN site seems to have limited documentation. 3) Nginx is well proven in production. Sometimes just being incumbent is a good reason. This often takes some large project or company taking a risk on the platform, proving it in the process; this is unlikely due to #1. 4) Other benchmarks indicate otherwise in regards to G-WANs performance; not to say its bad, but the selection of benchmarks on its site is likely biased towards it.
There may be many other reasons...
As far as I can tell, G-WAN does not support the features or languages that many people want. As a Ruby programmer, G-WAN is (probably) impossible for me to use, and if I could fiddle with it enough to get it working, it would not provide enough of a benefit to justify replacing a working nginx setup.
There's also the prevalence of tutorials, books, and StackOverflow answers related to nginx; G-WAN is pretty sparse in this regard.
Basically: the eternal balancing act of "features" vs "speed." nginx hits a sweet spot for features & speed for more people than G-WAN.
G-WAN is an all-in-one solution because communicating with other servers (FastCGI, SCGI, etc.) takes time (enlarging latency), and wastes CPU and RAM resources when the network can be avoided. Also, supporting many programming languages lets G-WAN serve most needs instead of having to use slower backend servers and fontend caches. Remember that our goal here is to use the ultimate low-latency and resource-saving solution. This is why G-WAN is a:
-Web server -App. server -Cache server -Key-Value store server -Reverse-proxy and elastic load-balancer server
http://tomoconnor.eu/blogish/gwan-snakeoil-beware/ was a good read.
Full disclosure: I'm one of the authors behind the Phusion Passenger application server (https://www.phusionpassenger.com), built on Nginx. What I'm saying here is based on my experience with Nginx module development and research into Nginx code.
As far as I see, the main reason why Nginx is fast is because the programmer is brilliant. No, seriously. Look at the code. There are almost no comments, there are no unit tests, and yet Nginx has no well-known stability bugs, or even performance regressions. There are also tons of micro-optimizations, some of which are of questionable nature on modern CPUs (e.g. the huge switch statements in the HTTP parser). The Nginx code goes into great pain to ensure that there are no unnecessary copies or memory allocation. Everything assumes that you use static string structs that point to already-allocated memory instead of dynamically allocated strings. In return, writing an Nginx module requires extreme programmer discipline. Almost everything is hard.
Compared to Apache, Nginx's main reason for being faster is because (1) it's evented and (2) it has a lot less features than Apache. No .htaccess - implementing .htaccess is a huge performance penalty because suddenly on every request you have to perform additional filesystem operations. No dynamic spawning of processes (unless you use Phusion Passenger). No dynamic loadable modules, so if you want to add anything you have to recompile Nginx entirely.
As for praising, well, I had no intention to read the code very carefully, but what I been able to gather from it, it was well-designed before being written, and it evented nature - processing multiple requests at different stages in a single process, looks very much like a instruction pipeline of a modern CPU, at least to me. That's, probably, the reason behind its name - an engine.
The only reference to "GWAN" I could find refers to a mysterious NSA system [1].