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.
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.
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.
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.
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?
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.
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.
"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.
served small files about 40% faster;
served larger files about 5% more slowly and;
used 3MB instead of 30MB.
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.