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.
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.
You must be nginx with such a fast response.
I think this is a fairly common sentiment towards Apache from developers who have to deploy their own stuff. I've certainly been in that camp more than a few times in the past. We're talking about:
- RAM usage
- Just being slow to push out simple files
- mod_php being the worst thing ever written
- mod_python disproving the last statement and taking the crown
- Various FastCGI/WSGI toolchains just not being up to scratch either.
I moved to nginx and Cherokee and suddenly configuration was both compact and modular and the settings seemed to make a real difference. RAM usage is completely minimal and performance is scorchingly hot. In more than one case I took an Apache box, switched Apache out and we were using half the RAM for the same jobs, and getting better performing websites, with less configuration.
I'm certain Apache could have been tuned but I don't think it's unreasonable for a developer to blame the software if you have to do a three year BSc in Apache Administration just to get something equivalent to 30 minutes playing in nginx.
I truly do hope that things are improving (competition is key in this environment!) but now I've left Apache on multiple servers, they're going to need to do more than just say "If you tune it, it can now match nginx speed", because my time is valuable too. I'm not going to jump back in until for most deployments it "just works".
Get off the rant, you were too stupid to figure out Apaches awesomeness so it spit you out, NginX took you in as it takes everyone in.
Well, I like my http servers like I like my women: fast!
I too like my webservers like I like my women: Insecure and full of holes waiting to be exploited. That's what I run Microsoft's IIS.
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.