Nginx just became the most used web server among the top 1000 websites
w3techs.com
w3techs.com
Both nginx and Apache are absolutely solid pieces of software. I wish we had as many alternatives to Microsoft Excel as we do IIS.
Anything below 7.5 I hope I never have to touch again...
the only reason a web daemon has an API in windows is because the windows registry is opaque, error-prone and in general, a giant piece of shit.
That said, I agree that it would be better if it isn't a thousand lines, and maybe there are better options than XML.
The company I work for is a Microsoft shop (for now, switching to Java sadly), and I've edited a lot of web.configs in servers, sometimes using Notepad, and it wasn't much of a hassle (though I did have to research what to edit beforehand in some cases).
Also, with the API you should be able to configure IIS without restarting it, while changing web.config recycles web apps (in ASP.NET scenario). With load-balancing, however, this is less of an issue.
Outside on the open Internet I absolutely agree that Apache and Nginx are the default HTTP servers. I switched from Apache to Nginx years ago (with a few exceptions) as it just seemed as though I could do more with less with it and it made sense for me to standardise.
According to the linked article, IIS has only 16% market share overall, and less than 11% of the top 1000 websites, so I'd say yes.
Similar to how Apple takes ~75% of the handset market profits, IIS takes almost all the profit in the web server market and is increasing revenues year after year.
It does quite well for itself given that the competition is fierce and free.
If you apply a set of criteria then that is the result.
The more interesting metric (though hard to quantify) is how much is earned with software.
http://www.zdnet.com/blog/stewart/adobes-q1-financials-show-...
I would think ASP.NET/C# would make the most profits in the dynamic web language space.
My point being that CF has a license, whereas Ruby and Python do not - which has little value in gauging success, a la IIS v Apache/nginx. (Ignoring the reality of open source Railo and Open BlueDragon for the moment)
They also both have licenses, but they don't charge money to obtain a copy.
All of our high profile sites have layers of caching and load balancing between them and the Apache backends that actually generate the content. In our case Nginx is in fact on the public facing end performing reverse proxy and TLS termination only. That is not to say Nginx isn't a fantastic product, but it may not be entirely fair to Apache, Varnish, and friends to measure HTTP server marketshare in this way.
I think more and more php-based app are powered by this kind of stack.
Anyway, Apache these days is mostly set-up with fastcgi or php-fpm due to these issues and this has the added good that you can use the worker or event mpm, though most benchmarks are still with the older prefork mpm.
"Apache and nginx, both open source web servers, have
lost market share this month whilst Microsoft gained
significantly, up by 2.43 percentage points, to just shy
of 20% of worldwide sites. For the second consecutive
month, nginx is powering fewer sites than in the previous
month's Web Server Survey, which is due, in part, to
almost 2M sites moving from nginx and to Apache. Within
the million busiest sites, a similar picture emerges:
nginx lost over 4,000 busy sites, many of which have
moved to Apache."
Not to saying that the picture may not be different in the top 1k.
Many people recognize that it's much cheaper to place nginx in front of other web servers than to buy more servers. We could say that nginx is mainstream now, so any serious website would use it. If you take "top million websites" instead of "top 1000", you might see different percentages. Automated tests just see nginx in the header, although something else is the actual workhorse for the site.
Some of the stuff does not need Apache anymore. As I moved almost all my projects from PHP to Node.js, there's little use for Apache now. And nginx serves static content with less CPU and RAM.
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?
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.
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.
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
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...
The only reference to "GWAN" I could find refers to a mysterious NSA system [1].
But it's a pretty thin layer with the real "web servers" behind it.
And no one will know IIS is behind it because it's a proxy. These stats don't tell the whole story.
EDIT: Found it. This post http://w3techs.com/blog/entry/w3techs_surveys_are_now_based_... implies they are using Alexa's rankings.
I can see at least two ways to interpret this:
1. nginx is just strictly better, and the sites at the top need that performance/capability and employ the top/best-informed architects to maintain their systems, so they're the early adopters. Everyone else is still on Apache by virtue of inertia, but will slowly move over as time goes on.
2. nginx is faster for high concurrency, and mostly gets used as a front-lines layer in front of something else, maybe even Apache itself. In this case, the charts will stay about like they are now, because only the most stressed sites need that much engineering.
I don't know that there's an easy way to differentiate between the two without either waiting and watching for change or knowing more about the internals of the top few thousand sites.
Also, should I stop using LAMP stack for my small and experimental PHP websites that very few people visit, or is it good enough?
There's a list of all the official Apache modules at https://httpd.apache.org/docs/current/mod/. Also, there are many third party modules.
Apache can serve as a reverse proxy to a web server, or even a fully functional forward proxy for lan users to the internet.
Nginx was never meant to have more features than Apache, it's intended to be lightweight and fast.
If you can imagine it, Apache is likely to have a module for it. With nginx, not so much.
Apache, by contrast, approaches large numbers of requests by spinning off more processes to handle them, typically consuming a lot of RAM as it does so. Apache looks at the elephant and thinks about how big it is as it tucks into its meal, and sometimes Apache gets a little anxious about the size of its repast. Nginx, on the other hand, just starts chomping.
The difference is summed up succinctly in a quote by Chris Lea on the Why Use Nginx? page: "Apache is like Microsoft Word, it has a million options but you only need six. Nginx does those six things, and it does five of them 50 times faster than Apache."
Source: http://arstechnica.com/business/2011/11/a-faster-web-server-...
For larger scale deployments, nginx is generally considered to perform better than apache.
There is the ability to use Lua with MySQL, PostgreSQL, MemCache, Redis, Upstream etc to perform functions of an app server e.g. authenticate users, serve JSON from a database. It's fast and keeps your app layer focused on real business logic.
If you already have Apache, don't bother switching. If you're starting new, use Nginx.
With modphp in limited memory environments you run into memory swap issues super fast unless you are careful about your Apache configs, since it will, in most default environments, spawn many more Apache processes than you have memory for. PHP makes the Apache process use 20-200M of memory for many standard apps like drupal or wordpress. Put it on a 1Gig linode without turning down the MaxClients and add 10 concurrent users and you will see the site grind to a halt. Now install nginx and php-fpm and follow anyone's basic how-to, it will only spawn as many php processes as your memory and cpu cores can handle, and nginx will keep spinning out the static files while php is churning in the background, living within reasonable memory bounds.
You can achieve the same thing in Apache, but I never really knew how to do that until Nginx taught me. I have never seen Apache set up right for this in any of my clients' existing servers and they can never scale at all.
Modphp is a bit faster if you have enough memory for your PHP application * the number of simultaneous connections, but that is hardly ever the case, since Apache will be reusing the same high memory processes for every jpg and css file that it does for all of the php requests and 2-3 simultaneous users can make 20-30 concurrent requests. You better make sure that your maxclients is set to your physical memory divided by your php app's memory use. In a 1G VPS this might be 1024M/64M = 16. Save some memory for MySQL if it is on the same server and you probably shouldn't have MaxClients over 10. Now all of the css, jpg and png files are waiting in-line for the 500ms php scripts to finish and the site loads slow. Many PHP apps eat up over 128M per process, even though a typical request is smaller, that one crazy request eventually bloats all of the processes and you are swapping. If PHP starts hitting swap, your request times are rising up to 3-5 seconds real quick.
Chris Lea
Also, I can't imagine anyone running NGINX without having access to the config file.
However since using nginx I have done away with caching as it is so much faster than apache + caching that I don't really need it.
You configure WPS to spit out gzipped copies of each page on disk, then you configure nginx to serve gzipped pages directly whenever they are found (gzip_static and try_files).
Basically you can serve compressed pages straight off disk. And thanks to the miracle of operating system file caching, it's usually straight from memory.
As far as I know, nginx can do anything Apache can do. nginx is generally faster than Apache. Apache can include modules without a recompile, nginx often requires you recompile to add features. nginx can be used as a reverse-proxy, a load balancer, or a thin SSL / SPDY layer, and succeed; Apache isn't as well suited to non-traditional web serving.
Personally, I find nginx's configuration syntax nicer to read and write than Apache's.
LAMP is fine for small experimental websites. Do what you're comfortable with! The scale at which the differences between nginx and Apache actually matters is pretty large.
Anyone trying to argue for nginx on the basis of better feature support (over apache) is blind to the reality of things.
And with NGINX I understand _every_ line in the configuration files, with Apache it was almost like configuring by coincidence.
It's plenty good enough; it's worked for decades already. If it ain't broke don't fix it. If traffic on a site is ramping up to the point where you're thinking "I might need to get new hardware for this soon", that's the time to start looking at a higher-performance webserver.
And honestly I'd look at moving away from PHP more urgently than moving away from Apache, if only because of their respective security records.
In my opinion, this is like moving away from C due to its security record.
Just my opinion.
Awesome stuff!
IIS must be on the second place, btw, considering how much man-hours and millions of USD were spent on it. We all know that MS technology is superior and very scientific.)
Nginx is rising because it deserves to, all others are more or less declining because they fail to catch the attention of the average sysadmin.
On the other hand, I use nginx as a reverse proxy in front of hypnotoad[1] so I might be unusual..
[1] http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#Hypn...
Are you talking about the JVM or LuaJIT? The OpenResty benchmarks make use of nginx' Lua interface (along with other nginx modules).