Why does no one pick it anymore? The reason is twofold: (1) the amount of FUD that surrounds it, based on old comparisons of nginx and Apache httpd 1.3 or 2.x using Prefork and (2) cool-kid syndrome. This thread itself is a perfect example.
Hmmm... looks like nothing more than a weblog analyzer. Someone correct me if I'm wrong. It's not "real time" since it can only report on what the web-server has done not what it is doing. AFAIK, nginx has nothing like Apache httpd's mod_status... at least, nothing open source.
It is amazing, and sad, how many people still refer to this document today when complaining about how "threads are bad" and "events are the bee's knees" or when justifying some architectural decision to avoid threads. No one prototypes anymore. No one does their own real world testing and benchmarking. They simply Google for some docs which support their already-made decision and call it a day.
If nginx has dubious copyright, you cannot fork the code, since not being open source, it is legally not-forkable. Yes, you could do a complete rewrite, but that would require doing so in a "clean room" fashion, which would be very difficult.
I loved A/UX... it was a fun OS, and porting various software to it was a great way to learn things. It also got me seriously involved in the Free Software and Open Source movements with my work on jagubox.
I especially love how the benchmark totally addresses the "events are always good and threads are always bad" FUD... Performance is a balance, not a simple, knee-jerk pronouncement.
Why not? Apache 2.4 with the Event MPM is async and event-driven, just as fast as nginx, lower latency, more fully compliant w/ RFC specs, robust reverse proxy w/ load balancing and dynamic configuration, super-fast caching,... and fully and completely open source.
"It's still living in the world of one process or one thread per connection."
It hasn't lived in that world for a decade or so. It's great to give advice, but at least make it valid and factual. With the Apache 2.4 event MPM, httpd is async and event-driven and is just as fast as nginx.
The problem, of course, when all contributions are "limited" to those within the company, that the talent and expertise required to keep things going exist just in the company itself, and not in the overall open source community. So when the company behind the tech "goes away", all the knowledge does too. It's for that reason that open source that is totally under the control of one company is so dangerous. Sure, you have the ability to fork, but the reality is that such a fork is almost assuredly doomed to fail. You really are beholden to that company.
Kind of sad that compliance never given as much importance as it should have... What good is a fast server if it doesn't fully comply w/ the spec? Luckily, there are some, like Apache httpd, that do both.
A/UX used the 68k microprocessors and would have needed to be ported to the PPC chip to be viable. A number of us A/UX hard-core fans really pushed Apple to do so, but instead, Apple decided to drop A/UX in favor of some sort of combined effort with IBM and their AIX system (which never panned out).
If people don't agree with what it means, it's because they aren't spending time reading the actual dissertation. Instead they are kind of glancing over it and depending on others interpretations to create their own. As someone who writes protocol specs, Roy takes great care in being as clear as possible: confusion, inconsistency and misinterpretation are not Worthy Things in protocol implementations. To truly understand REST, you MUST understand HTTP and the rationale behind it.
If you want the super best performance, throughput and latency wise, and don't care about memory, then Apache prefork would be the way to go. Just make sure that Apache never needs to fork any new processes after startup.
Usually, of course, there are tradeoffs. In those cases, Apache w/ Event MPM is just as scalable, efficient and concurrent as nginx. Just make sure you are running Apache httpd 2.4.x on a modern OS, to make use of the non-blocking and async I/O and event handling of Apache httpd.
It's called the Ostrich Solution. You stick your head in the sand to ignore alternatives to buttress the argument that your solution is the sole solution to a problem. You then hope that no one does even the most rudimentary investigation, which is, unfortunately, getting more and more prevalent nowadays.
Not all the time... Before, when nginx was event and Apache was prefork or worker, yeah. But with the Event MPM, performance is pretty much neck-and-neck.
Lots of reasons. First of all, it is fast and reliable. The choice of MPMs allow for sys-admins to choose exactly how they want httpd to scale. Unparalleled RFC compliance. Load balancing with dynamic, runtime configuration. Failover. .htaccess file. Full support for FPM/FastCGI. Fully Open Source and community driven (not Open Core). mod_rewrite capability. Hundreds of modules for almost every and all situation. Most people simply take the "lazy" route and not even investigate httpd, instead relying on the FUD about much older versions (you still get, for example, the screed that "Apache forks off a new process for each request")... Apache httpd 2.4 is just as fast and reliable as any other web-server out there, nginx included. It's just not seen as the "cool and hip" web-server. I guess some people are more concerned about marketing.
"all the problems" are really old, old news, long ago addressed and resolved. In fact, such statements are more FUD than anything else. Certainly you MUST know that Apache httpd supports PHP-FPM, for example.