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.)
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.
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!
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.
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.
[+] [-] wyclif|14 years ago|reply
[+] [-] atuladhar|14 years ago|reply
Is there any more information on how they arrived at this conclusion?
[+] [-] saurik|14 years ago|reply
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.)
[+] [-] selectnull|14 years ago|reply
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
[+] [-] ZenDan|14 years ago|reply
[+] [-] lrobb|14 years ago|reply
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.
[+] [-] ck2|14 years ago|reply
[+] [-] rickmb|14 years ago|reply
For 99% of all LAMP implementations, the performance of the stack is not an issue.
[+] [-] dpcx|14 years ago|reply
[+] [-] nextparadigms|14 years ago|reply
[+] [-] atuladhar|14 years ago|reply
[+] [-] tutu55634|14 years ago|reply
Event MPM seems unreliable :-(
[+] [-] madaxe|14 years ago|reply
[+] [-] absconditus|14 years ago|reply
http://news.netcraft.com/archives/2012/02/07/february-2012-w...
[+] [-] billpatrianakos|14 years ago|reply
[+] [-] batista|14 years ago|reply
You run the distro provided Nginx? Or the distro Ruby/Python/etc?
Really?
[+] [-] killitwithfire|14 years ago|reply