Slashdot Mirror
Apache 2.4 Takes Direct Aim At Nginx
darthcamaro writes "The world's most popular web server is out with a major new release today that has one key goal — deliver more performance than ever before. Improved caching, proxy modules as well as new session control are also key highlights of the release. 'We also show that as far as true performance is based — real-world performance as seen by the end-user- 2.4 is as fast, and even faster than some of the servers who may be "better" known as being "fast", like nginx,' Jim Jagielski, ASF President and Apache HTTP Server Project Management Committee, told InternetNews.com." Here's list of new features in 2.4.
So, your claim is that software can never improve?
I struggled with Apache 2 for at least 4 years before switching to NginX. It was the best thing I ever did.
Quick translation into English: 'I am too clueless to run a webserver, but wish to get First Post'.
I'm old enough to remember when discussions on Slashdot were well informed.
IANA web admin, but from what I have learned from playing around with both Apache and Nginx is that they serve different markets.
Nginx is a small, fast, reliable web server that is great for virtual machines, home users, newbies (like me), etc. It is simple and "just works" because it make sense. Nginx is the Ubuntu/Mint of the web server world.
Apache is a massive, feature rich, highly tunable, beast that can inter-operate with everything. This is an enterprise class (or at least very serious workload) web server. Designed by people who know what they are doing for people who know what they are doing. Apache is the Slackware/Gentoo of the web server world.
If you need a web server to get a job done, use Nginx. If the web server is your job then Apache. The key is how much time you have to spend figuring out how to customize Apache just right vs. how much those customizations are worth.
+1. Really, it's not even about performance or that Apache guys are bad at software. Far from it. The real crux is that Apache has become the Kitchen Sink of webservers. It can do *anything*, and there's always a complexity cost for that. Nginx can't do everything, but it's a really efficient and minimalist implementation of what 97% of modern deployments actually need, and none of the things they don't.
In some meta-sense, all software goes through this cycle: You're the best, everyone uses you, everyone files niche feature requests, you actually implement all of the niche features, and next thing you know 10 years later you're the Kitchen Sink implementation of domain X, and someone comes along and throws out all the irrelevant bullshit and makes a leaner implementation of just what matters *today*.
IMHO, the answer is that dropping features needs to be as easy as adding them. Too many software projects/architects have an easy-in, hard-out policy on features. "We can't drop feature X, it's been there for years and some crazy people in siberia still use it". It's ok to drop features on major-cycle releases. Perhaps even necessary for long-term project health.