To celebrate the 17th anniversary of its legendary Web server Apache HTTP Server the Apache Foundation released version 2.4 of the server today. It’s the first major update since version 2.2 in 2006 (there was a 2.3, but it was only released as a beta). According to the announcement, the new version adds several features that make the application more suitable for cloud environments.

The new features include:

• Improved performance (lower resource utilization and better concurrency)
• Reduced memory usage
• Asyncronous I/O support
• Dynamic reverse proxy configuration
• Performance on par, or better, than pure event-driven Web servers
• More granular timeout and rate/resource limiting capability
• More finely-tuned caching support, tailored for high traffic servers and proxies.

You can find more details on the new features here.

The asynchronous i/o support and reduced memory is particularly relevant as alternative Web servers as nginx and those written in Node.js increase in popularity. Apache has come to be seen as slow and bloated compared to newer servers like nginx, lighttpd and LiteSpeed. As we reported in January, nginx is one of the fastest growing open source projects in the enterprise while HTTP Server is trending flat, according to research conducted by OpenLogic. We’ve also seen a rise of language specific servers like Node.js, Mongrel and MochiWeb.

Which isn’t to say that HTTP Server is in any immediate danger – it’s a venerable Web server and is still by far the most popular Web server in the world according to research conducted by Netcraft (here’s Netcraft’s data at the time HTTP Server 2.2 was released). But it’s great to see Apache updating to keep up with the changing nature of the Web. According to a presentation given by Jim Jagielski at ApacheCon 2011, Apache’s own benchmarking puts 2.4 on par with nginx for concurrency.

I’m also interested in the improved caching support, since many people who still use Apache couple it with Varnish Cache to squeeze nginx-like performance out of it. Here are the mod_cache updates from the documentation:

The mod_cache CACHE filter can be optionally inserted at a given point in the filter chain to provide fine control over caching.
mod_cache can now cache HEAD requests.
Where possible, mod_cache directives can now be set per directory, instead of per server.
The base URL of cached URLs can be customised, so that a cluster of caches can share the same endpoint URL prefix.
mod_cache is now capable of serving stale cached data when a backend is unavailable (error 5xx).
mod_cache can now insert HIT/MISS/REVALIDATE into an X-Cache header.

In short, this is a major update for HTTP Server and brings it more in line with the demands of next generation websites.