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.
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.
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.
"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.
You must be nginx with such a fast response.
Quick translation into English: "I like my sendmail-esque configuration just fine. It's job security."
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.
What about easy?
DNA -- National Dyslexic Association
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.
There, in fact, is a very good reason for that. The very fundamental architectural decision (although very common in those ancient times) of spawning one thread/process per client connection has to be changed first, before Apache can take on Nginx. That means complete rewrite; and result will not be Apache anymore.
I'd rather have better control features, such as completely redoing the vhost matching method.
now we need to go OSS in diesel cars
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...
And how would you do it w/o one thread or process per client? Multiplexing?
We actually need multiple web server models. Processes are needed for multi-user environments for security reasons. But that impacts performance for single-user environments. OTOH, Apache does process based stuff all wrong, too (they do execve() for CGI and that is where the performance dies).
now we need to go OSS in diesel cars
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.
I struggled with Apache 2 for at least 4 years before switching to NginX. It was the best thing I ever did.
You struggled to use Apache?
I appreciate you telling me this. You've enlightened me to add something to my hiring practices. Now I know to ask a simple Apache configuration question when I Interview someone. I definitely don't want to hire someone that has trouble using something as simple as Apache.
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".
What makes you think that extremely complex piece of software is supposed to be easy to setup, by just about everyone?
Developers can do their development on default setup, I don't see a problem with that.
If you need to use it on production setup (or replication of production setup), then get people who know what they're doing to configure it.
Oh come on guys!
Every software has it's place to run. httpd, IIS (sorry for mentioning this one), lighttpd, tux, nginx,
Still comparing? Go buy 1 GB more RAM. Or say "sorry, It's easier for me to work with nginx, because apache is too heavy for my brains".
How much more RAM does it take for high loads than nginx?
[root@node3 ~]# ps_mem.py |grep -E "RAM|httpd|php"
Private + Shared = RAM used Program
202.6 MiB + 50.1 MiB = 252.7 MiB httpd (190)
940.2 MiB + 831.4 MiB = 1.7 GiB php-cgi (189)
Private + Shared = RAM used Program
This is what I've got with > 250 req/sec @1.6GHz dual cores, 8GB RAM. what more can nginx give and for what?
Average: all 2.35 0.00 2.08 3.24 0.00 92.33
If you are running it as a balancer - you're wrong! Take LVS.
If you are running it as a filter - you're wrong! Take mod_security or appliances (most of them are based on httpd+mod_security+mod_proxy) - nginx can't do this.
For anything else - it doesn't matter - you're wrong, again.
1 GB RAM vs delay + reading books, code and googling.
Maybe default manner of apache configurations and default MPM's are too heavy for you with default modules and features?
If you are running it for performance and response delays - Yes, it will be slower than nginx with single dumb empty virtual host with 0 add ons. You just CAN'T do analysis of traffic, filtering without buffering it. So, good servers will always have delays. It's OK for internet, not critical. Using it not for internet? For backend? Then OK.
I'm happy with 2.2 too.
Yes, I do like some nginx tricks and I wish it to be in apache too, but I'll never say that apache cannot handle something or do something or eat more RAM. It depends how do you configure it with your CPU and RAM resources, optimize.
"It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
+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.
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..
I think that may speak more about the sort of jobs you get hired for and the people you work with, rather than Apache itself.
The Apache configuration layout that Debian uses combined with Puppet or Chef is goodness.
Apache is "simple" in the same way that PHP is: it has excellent documentation because it has to or else no one would ever be able to use it. I've been using it professionally since the late 90s and am reasonably happy and comfortable with it, but I still have to RTFM every time I want to do something non-trivial.
Dewey, what part of this looks like authorities should be involved?
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.
I don't think the op was saying that, just that switching to nginx was a significant improvement over Apache.
At one place I worked, I increased our server capacity by 3 times, simply putting nginx in front of apache as a reverse proxy. Another place I replaced apache with nginx and cut memory requirements by over half. There are some things nginx doesn't do well, but nginx is so good at what it does it's still worth using the two together.
From my reasonably extensive experiences with both, Apache comes across as a slow lumbering juggernaut designed to do everything, no matter the cost, whereas nginx was designed with nothing but speed and efficiency in mind.
I'm sure Apache can improve, but short of a total rewrite reflecting a change in their approach, I'd be doubtful it can overtake nginx.
The mistake is trying to use mod_php with a heavy PHP application, such as a a complex Drupal site, without a reverse proxy such as Varnish or nginx.
One trick I have been using for a few years is using Apache as a threaded server, with MPM Worker, and FastCGI but with fcgid, not mod_fastcgi. Works exceptionally well. For static files, Apache is now lightweight and does not use much RAM.
For details, see my article on Apache MPM Worker with fcgid.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.