Apache 2.4 Takes Direct Aim At Nginx

← Back to Stories (view on slashdot.org)

Apache 2.4 Takes Direct Aim At Nginx

Posted by timothy on Tuesday February 21, 2012 @04:33AM from the competition-drives-progress dept.

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.

17 of 209 comments (clear)

Min score:

Reason:

Sort:

Re:Apache Never Again by TheCRAIGGERS · 2012-02-21 04:41 · Score: 4, Insightful

So, your claim is that software can never improve?
Re:Apache Never Again by Simon+Brooke · 2012-02-21 04:43 · Score: 5, Insightful

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.
Noticeable improvement by Kohenkatz · 2012-02-21 04:46 · Score: 4, Interesting

I have been running Release Candidiates of Apache 2.4 for a few months, on an underpowered and overloaded old laptop. The performance improvements over 2.2 on that same computer are really quite noticeable.
Defaults still insane? by Guspaz · 2012-02-21 04:51 · Score: 4, Informative

Does this release fix one of Apache's biggest problems, that the default Apache config file assumes that you've got 10 gigabytes of RAM in your server? Stuff like setting maxclients to a default of 150 has got to be the single biggest cause of Apache servers blowing up at dedicated and virtual private server hosts.
1. Re:Defaults still insane? by Guspaz · 2012-02-21 05:19 · Score: 3, Informative
  
  There are a handful of workloads that can justify that sort of concurrency, but they're few and far between. Web applications with persistent connections (which you're obviously not doing with that amount of RAM), or serving up large files for download, that sort of thing. The typical case of a LAMP stack almost never requires it, and enormous loads can be handled with levels of concurrency orders of magnitude smaller than what you've got.
  People normally thing they want to handle tons of people at the same time, but handling 10x more client requests simultaneously typically means each one takes 10x longer to process; there's no performance advantage, and all you've managed to do is burn RAM.
  I won't say that your workload doesn't justify that sort of concurrency, because I don't know what your workload is, but 150 is not a reasonable default for the vast majority of applications. Certainly not for most LAMP installations, where 512MB of RAM is typical, and more than a gig or two is rare.
2. Re:Defaults still insane? by DuckDodgers · 2012-02-21 06:22 · Score: 3, Insightful
  
  If you're running your own machines, maxing out the RAM makes sense. It's a one time cost and the ongoing cost to power and cool the added memory is negligible next to the rest of your budget.
  
  But if you're renting capacity from a virtual hosting provider, adding more RAM sends your monthly costs through the roof. Since tens of thousands of little websites run in that type of environment, it's a serious problem for a lot of low and lower-middle tier companies. I'm starting to think cloud hosting for small companies only makes sense financially if they write all their server code in C and C++. (Scary)
  
  I don't think it really matters what Apache makes the defaults, as long as there's plentiful, clear documentation on what the configuration parameters mean and how to make an educated guess as to what values you should set for your own deployment.
A bit bitter are we? by PhrostyMcByte · 2012-02-21 04:53 · Score: 4, Informative

"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," Jagielski said.
What's with the quotes? Other servers have proven to be faster, lighter weight, and more scalable than Apache for a long time. Don't be bitter because you fell behind. Be happy that you're finally catching up.
Re:First post by Anonymous Coward · 2012-02-21 05:03 · Score: 5, Funny

You must be nginx with such a fast response.
What we need by Anonymous Coward · 2012-02-21 05:11 · Score: 4, Interesting

We need a fully async web server, like nginx, but with *full* support for fastcgi/http1.1 and connection pooling to the backend servers.
In case some people don't know, nginx uses http1 to connect to the servers, which means a new connection for reach request. Same thing for FastCGI. nginx opens a new FastCGI connection for each request, then tears it down once done, even though FastCGI supports persistent connections and true multiplexing.
nginx is awesome and I love competition, especially between opensource.
Re:Apache Never Again by OliWarner · 2012-02-21 05:19 · Score: 5, Interesting

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".
Re:Apache by Anonymous Coward · 2012-02-21 05:34 · Score: 5, Funny

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.
Fixes I'd rather have by Skapare · 2012-02-21 05:46 · Score: 3, Interesting

I'd rather have better control features, such as completely redoing the vhost matching method.

--
now we need to go OSS in diesel cars
Re:Apache Never Again by hcs_$reboot · 2012-02-21 05:47 · Score: 3, Interesting

Nginx is not only the performance, it's also the configuration syntax ; everything looks much more professional, concise, and logically designed.
The code also deserves a special mention: it's like when you look under the hood of your car/computer for the first time, where everything is clean, all cables are numbered and arranged meticulously. This is a good old C code that doesn't need extra comments to be understood.
Apache improved? Show me the comparison charts between Apache and Nginx, in a many-users multi-cores-cpus and loaded configuration. To be honest, even if Apache would be a bit faster using a bit less memory than Nginx (while I have some doubts about that), I'd still be reluctant to go back to Apache and its setup.

--
Slashdot, fix the reply notifications... You won't get away with it...
Ubuntu vs Gentoo by inhuman_4 · 2012-02-21 06:09 · Score: 5, Insightful

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.
Re:Apache Never Again by Anonymous Coward · 2012-02-21 06:26 · Score: 5, Insightful

+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.
Re:Apache Never Again by TheNinjaroach · 2012-02-21 06:49 · Score: 3, Insightful

I definitely don't want to hire someone that has trouble using something as simple as Apache.
Holy crap, do you even use Apache? At my job, I get to roll my own from source and I own every line of httpd.conf and each of our vhosts.

Simple is not the word I would use to describe it. "Specialized" is much more like it.

--
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
Re:Apache Never Again by hawguy · 2012-02-21 08:20 · Score: 3, Insightful

What makes you think that extremely complex piece of software is supposed to be easy to setup, by just about everyone?
What makes you think everyone needs an extremely complex piece of software when their needs are often quite simple?
Apache is big and complex, nginx is small and simpler. Often one works better than the other for a particular person's needs. If someone finds Apache difficult to set up and finds nginx to be easier, then telling him to get someone to set up Apache is not the answer since he already already has the answer he is looking for. If Apache wants to be that answer too, then they need to find a way to simplify configuration.