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.

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'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.

It's hard not to like nginx.

> 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.

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.