This is a very strange post. nginx is highly mainstream and anyone working with webservers in any capacity should have come across it a number of years ago.
You would think so, but I still see new projects started every day using Apache for something nginx would be a much better fit for. I think that mostly the admins and architects on these projects have simply never heard of nginx, or if they have, they don't really know what it does.
It seems like you're making the assumption that 'they' would choose nginx just because it's superior.
There are many reasons for them not to go with nginx. The biggest one is probably that it's just different. Managing it is different. Configuring it is different (regardless of any similarities). Testing is still required.
It's nothing new that a lot of people either want to be lazy or are afraid of taking risks.
Being 'better' alone isn't a good enough reason to expect everyone to switch.
Different is risky. Consider, for example, lighttpd, another lightweight Apache alternative. It was chosen for a certain project at a former workplace of mine. Not too very long afterward, significant problems with memory leaks started occurring on the deployments that used it, and I found myself tasked with fixing them.
I was unprepared and somewhat astounded to find that lighttpd does not support sending "large files" over CGI, FastCGI, or proxy connections, and the maintainers don't care (cf. http://redmine.lighttpd.net/issues/1283 ...)
Besides the waste of engineering time, customers were impacted.
Don't underestimate how much people prefer to work with what they know. There's been plenty of times when I've gone with Apache on a server just because nginx's benefits aren't going to make a huge difference and I've been using Apache long enough to be able to configure it in my sleep.
> I think that mostly the admins and architects on these projects have simply never heard of nginx, or if they have, they don't really know what it does.
Then let those admins and architects be hired by your competitors. I mean, whoever is skilled at a craft, must - not should - be aware of a few alternative tools. Even when they are not productive with those tools, at least they should be knowledgeable about how they stack against their tools of choice.
I'm using both Nginx and Apache, depending on my needs and goals. I still like Apache because of its stability, configurability and awesome collection of plugins available.
Example 1: I once needed to send all logs from all web servers to a central machine. Now I know there's syslog-ng and other stuff like that, but I've had pretty bad experiences with it and in this instance I just configured Apache to pipe the logs to a simple Perl script I wrote (you know, instead of to a file). This was for a website with 10 million of visits per day and this configuration is still in production and worked wonderfully well. Nginx can't do it.
Example 2: if you ever want to develop Python/Django/wsgi apps, one of the best choices you can make is mod_wsgi. mod_wsgi is a self-healing Python/wsgi server that just works and is integrated perfectly within Apache. Ruby's Passenger was inspired by it and there's no mod_wsgi for Nginx (somebody tried porting it, but the results were awful).
Example 3: PHP is bound to Apache and will forever perform at its best as an Apache module. If you try the alternatives, you're just shooting yourself in the foot. Some people are also placing Nginx in front of Apache, but IMHO those are resources that would be better spent on placing Varnish in front (a kick-ass reverse proxy cache that can also do load-balancing).
I do love Nginx though. It is freakishly fast and it uses few resources.
I'm not biased one way or the other, although I find nginx far easier
to work with than apache. And like many here, I've been working with
apache forever.
1. I have no problem consolidating logs. I don't know your particular use
case, though, so maybe you have an edge case that is tricky with nginx.
2. I tried using native wsgi on nginx and didn't enjoy it. So, I
switched to gunicorn. Problem solved. I run graphite and its clan via
gunicorn as a key process in many places; it's rock solid.
3. php fpm as a proxy behind nginx performs just as well as mod-php on
apache, if not better. It's a damn sight easier to scale.
So, I don't share your concerns about nginx. So far, I have found no
reason to reason to continue with apache.
The biggest win has been serving a huge throughput of static images for a
particular client's web-site. We sized a new machine under apache, but
when we deployed with nginx, it used a tiny percentage of apache's
resources.
my only complaint about nginx is the way it tries to make location ordering "magical". there's often no clear way of forcing a specific location assertion order because of regex vs literal, terminating vs not.
Yeah I agree about the location directive's magicalness being impossible to keep in my head for more than a couple minutes. I spend a fair bit of time configuring nginx and I constantly refer to this page:
"NGINX (pronounced “engine X”) is an open-source HTTP Web server that also includes mail services with an Internet Message Access Protocol (IMAP) and Post Office Protocol (POP) server. NGINX is ready to be used as a reverse proxy, too."
vs.
"While the other web servers differentiate by having lots of features and being something like a general purpose web software, NGINX excels in the set of key features associated with performance, scalability, and cost efficiency."
Which is it? I just want something that accepts HTTP(S) connections. In JavaLand, Jetty works pretty well using the non-blocking (select style) connector, and it's trivially embeddable.
It actually is sort of both. The core feature set is well designed and relatively slim, and supports the three most common topologies - as a front end for static content, as a front-end up for an external "web engine", e.g. php-fpm or rack or a WSGI app, or as a reverse proxy/load balancer.
It's a very good 90% solution - 90% of the time it does everything you need, and it does it well. That comes at the cost of supporting certain corner cases or features, WebDAV for instance.
Where it might not be as good as in something like a shared hosting environment where you want to give users something they can tweak like an .htaccess file. That sort of per-request configuration loading runs counter to the performance profile they're trying to provide.
> One of the leading alternatives, the open-source NGINX, is now the number two Web server in the world, according to Netcraft, the Web server analytics company.
Look at the graphs on that page. You'll see that Apache is still number 1 (as it has been for the past 16 years), still has by far the largest market share, and is still growing fast. Faster than Nginx if you look at total numbers.
Nginx's primary benefit is performance, gained from its event based request model. Guess what Apache 2.4 has... The same thing. The idea that Apache is dying is laughable.
A couple of years ago, I wrote a big bunch of scripts to benchmark about 10 web servers (Apache flavors, Lightspeed, Lighttp, nginx, etc) against each other. 300 concurrent requests; 5 different types of files; measured requests per second and ending RSS. In comparison to Apache worker-MPM, nginx:
served small files about 40% faster;
served larger files about 5% more slowly and;
used 3MB instead of 30MB.
The differences weren't enough to stop me using Apache. Interestingly Apache worker-MPM and event-MPM performed nearly identically.
A couple of years ago, I wrote a big bunch of scripts to benchmark about 10 web servers (Apache flavors, Lightspeed, Lighttp, nginx, etc) against each other. 300 concurrent requests; 5 different types of files; measured requests per second and ending RSS. In comparison to Apache worker-MPM, nginx:
served small files about 40% faster;
larger files about 5% more slowly and;
used 3MB instead of 30MB.
But the differences weren't enough to stop me using Apache. Interestingly Apache worker-MPM and event-MPM performed nearly identically.
I used nginx and lighttpd in the past, but I came across cherokee, which seems to work pretty good. I mainly changed because I realized all these cross-server DoS attacks/techniques that worked with nginx, apache, lighttpd always listed cherokee as an exception.
It also is a tiny bit faster on some occasions (while slower on others).
Somehow people don't seem to like it, because it has a pretty and optional(!) web interface that can be started to get things up and running quickly.
Well, no ad, but I always ask whether anyone knows a real benefit of other web servers. The only benefit I see in nginx is lua scripting, but seriously I would most likely not use that or use it for stuff I don't need to script on my own using cherokee.
29 comments
[ 3.4 ms ] story [ 56.3 ms ] threadThere are many reasons for them not to go with nginx. The biggest one is probably that it's just different. Managing it is different. Configuring it is different (regardless of any similarities). Testing is still required.
It's nothing new that a lot of people either want to be lazy or are afraid of taking risks.
Being 'better' alone isn't a good enough reason to expect everyone to switch.
I was unprepared and somewhat astounded to find that lighttpd does not support sending "large files" over CGI, FastCGI, or proxy connections, and the maintainers don't care (cf. http://redmine.lighttpd.net/issues/1283 ...)
Besides the waste of engineering time, customers were impacted.
Then let those admins and architects be hired by your competitors. I mean, whoever is skilled at a craft, must - not should - be aware of a few alternative tools. Even when they are not productive with those tools, at least they should be knowledgeable about how they stack against their tools of choice.
Example 1: I once needed to send all logs from all web servers to a central machine. Now I know there's syslog-ng and other stuff like that, but I've had pretty bad experiences with it and in this instance I just configured Apache to pipe the logs to a simple Perl script I wrote (you know, instead of to a file). This was for a website with 10 million of visits per day and this configuration is still in production and worked wonderfully well. Nginx can't do it.
Example 2: if you ever want to develop Python/Django/wsgi apps, one of the best choices you can make is mod_wsgi. mod_wsgi is a self-healing Python/wsgi server that just works and is integrated perfectly within Apache. Ruby's Passenger was inspired by it and there's no mod_wsgi for Nginx (somebody tried porting it, but the results were awful).
Example 3: PHP is bound to Apache and will forever perform at its best as an Apache module. If you try the alternatives, you're just shooting yourself in the foot. Some people are also placing Nginx in front of Apache, but IMHO those are resources that would be better spent on placing Varnish in front (a kick-ass reverse proxy cache that can also do load-balancing).
I do love Nginx though. It is freakishly fast and it uses few resources.
1. I have no problem consolidating logs. I don't know your particular use case, though, so maybe you have an edge case that is tricky with nginx.
2. I tried using native wsgi on nginx and didn't enjoy it. So, I switched to gunicorn. Problem solved. I run graphite and its clan via gunicorn as a key process in many places; it's rock solid.
3. php fpm as a proxy behind nginx performs just as well as mod-php on apache, if not better. It's a damn sight easier to scale.
So, I don't share your concerns about nginx. So far, I have found no reason to reason to continue with apache.
The biggest win has been serving a huge throughput of static images for a particular client's web-site. We sized a new machine under apache, but when we deployed with nginx, it used a tiny percentage of apache's resources.
It's hard not to like nginx.
So I would have thought that helps a fair bit with NGINX's market share stats.
Files behind a CDN are static files, such as CSS, JS etc. These are requested by other HTML files, which in turn include 10 of them maybe?
i just tweaked https://github.com/Xeoncross/wnmp a bit for my uses. buttery smooth goodness.
my only complaint about nginx is the way it tries to make location ordering "magical". there's often no clear way of forcing a specific location assertion order because of regex vs literal, terminating vs not.
http://wiki.nginx.org/HttpCoreModule#location
I still love it compared to Apache though in terms of ease of configuration.
seriously?
things I hate; english community support isn't great.
"NGINX (pronounced “engine X”) is an open-source HTTP Web server that also includes mail services with an Internet Message Access Protocol (IMAP) and Post Office Protocol (POP) server. NGINX is ready to be used as a reverse proxy, too."
vs.
"While the other web servers differentiate by having lots of features and being something like a general purpose web software, NGINX excels in the set of key features associated with performance, scalability, and cost efficiency."
Which is it? I just want something that accepts HTTP(S) connections. In JavaLand, Jetty works pretty well using the non-blocking (select style) connector, and it's trivially embeddable.
It's a very good 90% solution - 90% of the time it does everything you need, and it does it well. That comes at the cost of supporting certain corner cases or features, WebDAV for instance.
Where it might not be as good as in something like a shared hosting environment where you want to give users something they can tweak like an .htaccess file. That sort of per-request configuration loading runs counter to the performance profile they're trying to provide.
Netcraft confirms: Apache is dying.
http://news.netcraft.com/archives/2012/01/03/january-2012-we...
Look at the graphs on that page. You'll see that Apache is still number 1 (as it has been for the past 16 years), still has by far the largest market share, and is still growing fast. Faster than Nginx if you look at total numbers.
Nginx's primary benefit is performance, gained from its event based request model. Guess what Apache 2.4 has... The same thing. The idea that Apache is dying is laughable.
on a hunch, I looked at the OP's history; out of 27 links, 14 are to hp.com, and five are to softwarequalityconnection.com.
i suspect social media marketing.
It also is a tiny bit faster on some occasions (while slower on others).
Somehow people don't seem to like it, because it has a pretty and optional(!) web interface that can be started to get things up and running quickly.
Well, no ad, but I always ask whether anyone knows a real benefit of other web servers. The only benefit I see in nginx is lua scripting, but seriously I would most likely not use that or use it for stuff I don't need to script on my own using cherokee.