After 17 years of existence, the Apache HTTP web server is one of the most successful and dominant open source projects of all time. Today Apache is looking to extend that streak of success with the new Apache 2.4 web server release, marking the first major Apache web server update since the 2.2 release in 2005.
A key focus in the 2.4 release is improved performance which is delivered by way of multiple innovations.
“What we have done is checked 2.4 against itself and other web-servers; in general, we find 2.4 to be the fastest version of Apache by far,” Jim Jagielski, ASF President and Apache HTTP Server Project Management Committee, told InternetNews.com.
Jagielski added that with the different Multi-Processing Modules (MPMs) available in Apache 2.4, administrators can fine-tune Apache to be faster where it makes sense. For example, he noted that if there is a need for a super fast request/response, then the Prefork MPM might make sense. If there is a need for a super fast concurrency-tagged server, then Event is the ticket.
“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.
Nginx has emerged in recent years to be a rival of sorts to Apache, offering up a web server that has the promise of being faster in some situations. While Apache has long dominated the market as being the most widely deployed web server technology, Nginx is according to at least one metric, now in the number two spot.
Jagielski said that all web-servers and web-caches have their uses and sweet spots.
“With Apache 2.4,it is generic enough, powerful enough and now performant enough that it can be used in places where the multiple-box approach may have been used,” Jagielski said.
In a multiple box approach, there is the potential for additional latency, which is not the case in a single box Apache approach
“Of course, you could also use Apache as a replacement for either nginx or varnish or even replace both with Apache; that’s the power and flexibility that Apache 2.4 provides,” Jagielski said. “One reason to do it would be a single, consistent learning curve for both the web front-end as well as the caching layer.”
Apache Software Foundation committer Graham Legget told InternetNews.com that there were significant improvements made to Apache httpd’s mod_cache mechanism in order to support high traffic environments that are subjected to extreme traffic in a broadcasting and media environment.
“These improvements include support for serving stale data during the revalidation of expired content, as well as the serving of stale data as an alternative to an application server error,” Legget said. “The ability to place the cache precisely within the filter chain allows the option to cache application generated content, while personalising the same content further down the filter chain, without being forced to deploy separate caching layers.”
Additionally Legget noted that there have also been improvements to the cache reporting mechanisms. He explained that the cache can now report in detail why a particular response was or wasn’t cached, which can help developers and operations debug issues with potentially uncacheable or inefficient content delivery. Apache has also updated its httpd caching guide to better explain the operation of three-state RFC2616 HTTP caches, and how they can improve server performance: http://httpd.apache.org/docs/2.4/caching.html#http-caching
With Apache 2.4, proxy capabilities have also been significantly improved with the integration of mod_proxy and mod_proxy balancer.
“For the cloud, you want and need dynamic configuration: you need to easily and quickly add proxies, adjust load-balancing capabilities, turn-off backends, etc,” Jagielski said. “With 2.4, Apache allows you to do all that, also, in addition to the dynamic capability that cloud infrastructures demand, we also have the performance as well.”
Another new innovation in Apache 2.4 is the mod_session module for implementing sessions.
“We want to instead provide a service to module developers as well as sys-admins who have always needed to worry about implementing sessions, in one way or another,” Jagielski said. “Mod_session provides a universal framework that people can use, which has been lacking for a long time.”
Leggett added that a key reason for the development of mod_session along with mod_auth_form was to allow Apache httpd to handle the form based single sign on scenarios that are typically handled by application servers directly, usually in various incompatible ways.
“The idea is that httpd can be configured to worry about the sign on process, optionally passing the user credentials to applications running behind an Apache httpd reverse proxy using simple basic authentication,” Leggett explained. “This can help provide a common sign on mechanism in an environment where legacy or incompatible heterogeneous systems are present.”
The Future of Apache
For existing Apache 2.2.x users, migrating to 2.4 is quite easy, according to Jagielski. He noted that there are minimal configuration changes. He added that the vast majority of modules do not require any changes to run under 2.4; they just need to be re-compiled and then the work is done.
While Apache 2.4 is a significant release that add a lot, Jagielski said that there’s always more work do be done.
“We’re looking at really streamlining the internal filter chain, which provides flexibility but can slow things down,” Jagielski said. “We’re also looking at a new MPM called Simple which is as elegant, efficient and “simple” as possible, in order to get the best performance with the absolute minimum of resource utilization.”