New version of Apache HTTP Server released

https://blogs.apache.org/foundation/entry/the_apache_software_foundation_celebrates

by wyclif • 14 years ago

246 35 14 years ago

blogs.apache.org

wyclif• 14 years ago

New features: http://httpd.apache.org/docs/2.4/new_features_2_4.html

ZenDan• 14 years ago

It would be interesting to see benchmarks compared to nginx

lrobb2• 14 years ago

Those would be pretty much meaningless...

Apache can be tweaked in so many different ways depending on what your traffic patterns look like, and how you're processing your requests. MaxClients / KeepAlive / MaxRequestsPerChild / etc...

e.g. you would have a completely different config for serving wordpress vs static images for a photo album.

maratd4• 14 years ago

> Apache can be tweaked in so many different ways

I can't stress this enough. Besides all the configuration settings, you can really dig into the internals.

Our production deployment of Apache is custom-compiled with something like 90% of the modules disabled. Only the basic stuff we use.

Each deployment is unique, making benchmarks pretty useless.

If you need to choose which httpd to use, decide based on how easily it'll fit in your stack. I promise you, if you hit the performance ceiling on any of the httpd suites out there, you'll have bigger fish to fry.

rbanffy2• 14 years ago

Having a couple different common cases and configurations benchmarked wouldn't hurt...

modoc• 14 years ago

Plus it's pretty easy to saturate a 1 Gbit NIC with even a pretty close to OOTB Apache setup. You might burn 5-10% more CPU than if you were using nginx, but it's not that big a deal in 99% of the use cases.

madaxe2• 14 years ago

I thought I saw a squadron of pigs soar by this morning. Too little, too late, I think, though, as nginx & friends have devoured their market share over the years, and it's going to take a good year or two for distros to start supporting 2.4 - probably 7 or 8 years for RHEL!

killitwithfire• 14 years ago

brilliant. Shouldn't you be catching up on your codeacademy classes?

billpatrianakos2• 14 years ago

Why wouldn't distros support it? I'm not sure what you mean by that. I don't know, your comment sounds more like you have an irrational preference for Nginx because it's what the cool kids use rather than having any real issues with Apache. I do hope that distros start including 2.4 right away in their package managers but even if they don't that doesn't mean we can't install it with just a few extra keystrokes.

absconditus• 14 years ago

Apache continues to hover around 65% of the market while its next nearest competitor, Microsoft, hovers around 15%. nginx is below 10% and climbing very slowly.

http://news.netcraft.com/archives/2012/02/07/february-2012-w...

emilis_info• 14 years ago

It may be climbing slowly, but it is the only one climbing in all the categories.

batista2• 14 years ago

Who cares for distros? Lots of people employ custom stacks.

You run the distro provided Nginx? Or the distro Ruby/Python/etc?

Really?

orthecreedence• 14 years ago

Agreed. I compile and package just about every piece of server software by hand. There almost never a case where my ./configure options match the default options.

madaxe2• 14 years ago

No, we package up all of our own debs, as waiting for distro maintainers is like waiting for Godot. My point was that I honestly believe Apache's days are numbered, as their release cycle is practically moribund.

ck2• 14 years ago

Between this and PHP5.4, LAMP performance is finally progressing.

rickmb• 14 years ago

Although not untrue, this is also typical for the somewhat myopic HN-crowd way of looking at it.

For 99% of all LAMP implementations, the performance of the stack is not an issue.

Luyt• 14 years ago

Indeed, the performance bottleneck of a webapp is often the database. But isn't that what the 'M' in 'LAMP' stands for? MySQL? Now, if the 'M' would stand for memcached, things would be better. Maybe it's time for the 'LAMMP' stack ;-)

dpcx• 14 years ago

The last time I tried mpm_event, PHP shat all over the place because of the threading model. Has this improved?

maratd4• 14 years ago

Yes. On PHP's end. Use PHP-FPM.

selectnull• 14 years ago

With mod_lua, embedded lua interpreter.

I just couldn't resist, I had to try it at once. It works! (no pun intented, for those who get the reference).

edit: fixed typo

nextparadigms• 14 years ago

So no SPDY implementation then? Too bad.

atuladhar2• 14 years ago

There's http://code.google.com/p/mod-spdy/ -- not sure if it works with 2.4.

atuladhar2• 14 years ago

From the announcement: "Performance on par, or better, than pure event-driven Web servers."

Is there any more information on how they arrived at this conclusion?

saurik2• 14 years ago

The second "Core Enhancement" is: "The Event MPM is no longer experimental but is now fully supported.". I would imagine it is because that module's inherent design offers the same underlying system overhead benefits that people are claiming with their event-driven servers.

The idea is that Apache features "multi-processing modules", which control how incoming connections are eventually translated into the state of the running program. These are not just simple tweaks to a fixed pipeline: it is possible to drastically alter the mechanism. As an example: mpm_winnt can be drastically different than the Unix implementations.

The original implementation was mpm_prefork, which maintains a pool of fork()'d processes to handle incoming connections. However, the more reasonable installations have used mpm_worker for years now, which keeps a pool of threads in each process (developed back when thread pools were the rage).

However, a while back someone built mpm_event, which uses the same underlying system calls that people use to build their "purely event-driven servers" to handle the sockets. This has been marked "experimental" for a while, initially due to bad interactions with other modules that weren't quite prepared to be evented (such as mod_ssl), but honestly it has been stable for years.

(I've been using it in production on a site with tens of millions of users, with SSL, and if anything mpm_event made things run better by working around a really irritating issue in Python: specifically, that until very very very recently the Python libraries simply failed to handle EINTR in a reasonable way; mpm_event seems to setup the signal and thread environment in a way that made me stop getting entire outgoing HTTP API requests to fail with EINTR ;P.)

endgame2• 14 years ago

Can you go into more detail about the right way to handle EINTR? When I wrote a server I wound up using the "if at first you get EINTR'd, try, try again".

tutu55634• 14 years ago

Micro Benchmark of Apache 2.4 vs Nginx 1.0: http://blog.causal.ch/2012/02/micro-benchmark-apache-24-vs-n...

Event MPM seems unreliable :-(

New version of Apache HTTP Server released

Related Stories