5 ms·

Are there any significant barriers to use the event MPM as it stands in the 2.2. Does it fall back to worker when its used under SSL?

by mthomas 16y ago

bnoordhuis 16y ago
No. The main problem the event MPM addresses is HTTP keep-alive. With pre-fork and threaded, every connection takes up a process or thread. This sucks for keep-alive because it can take a while before the client issues the next request. The event MPM puts that idle connection in a kqueue/epoll/etc. pollset and recycles the process/thread for another request. It's a conceptually simple change but it has some profound performance implications.
brianm 16y ago
In 2.2, the event mpm doesn't support ssl, but in 2.3/2.4 it does support ssl. In fact, IIRC, if you are using apche as a reverse proxy (mod_proxy) the event mpm should become the standard as it will detach the worker thread both for keepalive on the front end, and when waiting on response from the backend.
saurik 16y ago
As a single datapoint, I run a site that handles many billions (this is not rhetorical or an exaggeration) of hits per month using mpm_event: I consider it the only sane/stable way of configuring Apache.
- patio11 16y ago
  As I found out to my sadness, the only sane configuration is not the one which ships with apt-get apache2. I like many things about Nginx. The fact that it is a production-capable web server out of the box, for example. I know that is probably not a high-priority design goal for Apache for historical reasons, but it seems a very sensible default in 2011.
  - saurik 16y ago
    For the record, "apt-get install apache2-mpm-event" is all you need to switch to mpm_event: I believe it isn't supported on all platforms, and, as a conservative Debian-based distribution using apt-get, I'd prefer "predictable behavior across all of our targets" over "highest performance configuration on any given system". (I also believe there are some corner cases where mpm_event may burn you on 2.2, and both Apache and Debian are going to play it safe there; but, when I looked into this in detail a forever or so ago, I determined that whatever issues they were didn't apply to my setup. As an example: if SSL were an issue, I doubt I would ever use Apache to directly serve SSL anyway, as that's what SSL accelerators are for.) That said, I still wouldn't leave the defaults in place with regards to "number of servers / threads"; although it isn't like nginx doesn't need the same configuration: the default value of worker_{processes,connections} is almost certainly inappropriate for your specific setup. I also use nginx (as a load balancer), and I have those values at 64/10096, up from the Debian-default of 1/1024. The important thing, to me, is what a technology makes possible, not how well it is configured out of the box. Example: it is more damning to me that nginx only does HTTP/1.0 to upstream servers it is proxying for, a reasonably fundamental limitation of the codebase, than any transgression they could make in their default configuration. Seriously: production is not about "out of the box", it never was, and it likely is never going to be. If you are trying to run a production server using "out of the box" defaults you are going to be forever disappointed by the performance and functionality of the offerings. To make a minor modification to a statement I've made before (http://news.ycombinator.com/item?id=2145967 http://news.ycombinator.com/item?id=2145967 is the reference) about database servers: We (as a civilization) simply do not have the science and theory yet to make the practicalities of setting up and maintaining anything at this level of complexity a totally seamless and simple process with well-understood performance characteristics unless you constrain absolutely every single variable.
    - patio11 16y ago
      If you are trying to run a production server using "out of the box" defaults you are going to be forever disappointed by the performance and functionality of the offerings. I have sold hundreds of thousands of dollars of software to thousands of people which has run for years without (web-server related) incident on nginx. If I am fated to be struck down for my ignorance of nginx internals, that doom must be further down the road. Where I do see failure is when I put the world's most popular blogging software on Apache, turn on caching and give it a gig of RAM to play with, and then watch the server get denial-of-serviced by the totally innocent actions of any ten readers attempting to access the website in a 15 second interval. Thank you, KeepAlive. Ten is not a big number on the Internet. Apache has been DOSed by my younger brother's comic book writing advice blog. I accept that, for historical reasons, the Apache project does not optimize for being useful without being a master of arcane trivia like knowing what options the server is compiled with (!) to be able to operate a college student's blog (!!) without falling off the Internet. Much software developed these days pitched at web developers, including software which I write, has as a guiding design principle that you should be able to start using it in five minutes following simple instructions and those sensible defaults should mostly work. I think this development model is categorically better than software-by-the-experts, software-for-the-experts models. P.S. apt-get mysql gets you a database which won't fall over if you try to host a comic book blog on it.

Are there any significant barriers to use the event MPM as it stands in the 2.2. Does it fall back to worker when its used under SSL?

by mthomas 16y ago

Are there any significant barriers to use the event MPM as it stands in the 2.2. Does it fall back to worker when its used under SSL?

bnoordhuis 16y ago

No. The main problem the event MPM addresses is HTTP keep-alive. With pre-fork and threaded, every connection takes up a process or thread. This sucks for keep-alive because it can take a while before the client issues the next request. The event MPM puts that idle connection in a kqueue/epoll/etc. pollset and recycles the process/thread for another request. It's a conceptually simple change but it has some profound performance implications.

brianm 16y ago

In 2.2, the event mpm doesn't support ssl, but in 2.3/2.4 it does support ssl. In fact, IIRC, if you are using apche as a reverse proxy (mod_proxy) the event mpm should become the standard as it will detach the worker thread both for keepalive on the front end, and when waiting on response from the backend.

saurik 16y ago

As a single datapoint, I run a site that handles many billions (this is not rhetorical or an exaggeration) of hits per month using mpm_event: I consider it the only sane/stable way of configuring Apache.

patio11 16y ago
As I found out to my sadness, the only sane configuration is not the one which ships with apt-get apache2. I like many things about Nginx. The fact that it is a production-capable web server out of the box, for example. I know that is probably not a high-priority design goal for Apache for historical reasons, but it seems a very sensible default in 2011.
- saurik 16y ago
  For the record, "apt-get install apache2-mpm-event" is all you need to switch to mpm_event: I believe it isn't supported on all platforms, and, as a conservative Debian-based distribution using apt-get, I'd prefer "predictable behavior across all of our targets" over "highest performance configuration on any given system". (I also believe there are some corner cases where mpm_event may burn you on 2.2, and both Apache and Debian are going to play it safe there; but, when I looked into this in detail a forever or so ago, I determined that whatever issues they were didn't apply to my setup. As an example: if SSL were an issue, I doubt I would ever use Apache to directly serve SSL anyway, as that's what SSL accelerators are for.) That said, I still wouldn't leave the defaults in place with regards to "number of servers / threads"; although it isn't like nginx doesn't need the same configuration: the default value of worker_{processes,connections} is almost certainly inappropriate for your specific setup. I also use nginx (as a load balancer), and I have those values at 64/10096, up from the Debian-default of 1/1024. The important thing, to me, is what a technology makes possible, not how well it is configured out of the box. Example: it is more damning to me that nginx only does HTTP/1.0 to upstream servers it is proxying for, a reasonably fundamental limitation of the codebase, than any transgression they could make in their default configuration. Seriously: production is not about "out of the box", it never was, and it likely is never going to be. If you are trying to run a production server using "out of the box" defaults you are going to be forever disappointed by the performance and functionality of the offerings. To make a minor modification to a statement I've made before (http://news.ycombinator.com/item?id=2145967 http://news.ycombinator.com/item?id=2145967 is the reference) about database servers: We (as a civilization) simply do not have the science and theory yet to make the practicalities of setting up and maintaining anything at this level of complexity a totally seamless and simple process with well-understood performance characteristics unless you constrain absolutely every single variable.
  - patio11 16y ago
    If you are trying to run a production server using "out of the box" defaults you are going to be forever disappointed by the performance and functionality of the offerings. I have sold hundreds of thousands of dollars of software to thousands of people which has run for years without (web-server related) incident on nginx. If I am fated to be struck down for my ignorance of nginx internals, that doom must be further down the road. Where I do see failure is when I put the world's most popular blogging software on Apache, turn on caching and give it a gig of RAM to play with, and then watch the server get denial-of-serviced by the totally innocent actions of any ten readers attempting to access the website in a 15 second interval. Thank you, KeepAlive. Ten is not a big number on the Internet. Apache has been DOSed by my younger brother's comic book writing advice blog. I accept that, for historical reasons, the Apache project does not optimize for being useful without being a master of arcane trivia like knowing what options the server is compiled with (!) to be able to operate a college student's blog (!!) without falling off the Internet. Much software developed these days pitched at web developers, including software which I write, has as a guiding design principle that you should be able to start using it in five minutes following simple instructions and those sensible defaults should mostly work. I think this development model is categorically better than software-by-the-experts, software-for-the-experts models. P.S. apt-get mysql gets you a database which won't fall over if you try to host a comic book blog on it.