Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
On 10/21/2008 01:09 AM, Nick Kew wrote: [EMAIL PROTECTED] wrote: --- httpd/httpd/trunk/modules/http/http_request.c (original) +++ httpd/httpd/trunk/modules/http/http_request.c Sat Sep 20 04:58:08 2008 @@ -257,24 +297,7 @@ ap_die(access_status, r); } -/* Send an EOR bucket through the output filter chain. When - * this bucket is destroyed, the request will be logged and - * its pool will be freed - */ -bb = apr_brigade_create(r-connection-pool, r-connection-bucket_alloc); -b = ap_bucket_eor_create(r-connection-bucket_alloc, r); -APR_BRIGADE_INSERT_HEAD(bb, b); -ap_pass_brigade(r-connection-output_filters, bb); - -/* From here onward, it is no longer safe to reference r - * or r-pool, because r-pool may have been destroyed - * already by the EOR bucket's cleanup function. - */ - -c-cs-state = CONN_STATE_WRITE_COMPLETION; -check_pipeline(c); -if (ap_extended_status) -ap_time_process_request(c-sbh, STOP_PREQUEST); +return ap_process_request_after_handler(r); } This is a compile error in a void function. What exactly was intended here? As ap_process_request_after_handler is a void function by itself I guess it should be simply ap_process_request_after_handler(r); instead of return ap_process_request_after_handler(r); but this is just a guess. Regards Rüdiger
Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
[EMAIL PROTECTED] wrote: --- httpd/httpd/trunk/modules/http/http_request.c (original) +++ httpd/httpd/trunk/modules/http/http_request.c Sat Sep 20 04:58:08 2008 @@ -257,24 +297,7 @@ ap_die(access_status, r); } -/* Send an EOR bucket through the output filter chain. When - * this bucket is destroyed, the request will be logged and - * its pool will be freed - */ -bb = apr_brigade_create(r-connection-pool, r-connection-bucket_alloc); -b = ap_bucket_eor_create(r-connection-bucket_alloc, r); -APR_BRIGADE_INSERT_HEAD(bb, b); -ap_pass_brigade(r-connection-output_filters, bb); - -/* From here onward, it is no longer safe to reference r - * or r-pool, because r-pool may have been destroyed - * already by the EOR bucket's cleanup function. - */ - -c-cs-state = CONN_STATE_WRITE_COMPLETION; -check_pipeline(c); -if (ap_extended_status) -ap_time_process_request(c-sbh, STOP_PREQUEST); +return ap_process_request_after_handler(r); } This is a compile error in a void function. What exactly was intended here? -- Nick Kew
Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
On 9/21/08 2:17 AM, Bing Swen [EMAIL PROTECTED] wrote: But an optimal network i/o model needs a layer that maps a *request* to a thread, so that a worker thread (or process) will not have to be tied up entirely with a single connection during the whole life time of the connection. Instead, a worker can be scheduled to handle different connections, which helps both reducing the number of workers and the performance of request handling (especially on slow connections). I still want to see this backed up with real world experience. I know I keep repeating myself, but in the real world, we have never seen the supposed inherent performance problems in the worker model (1 connection = 1 thread). It sounds great to theorize about the wonders of a completely event driven or asynchronous model. However, it seems that this only nets real measurable performance gains is very simplistic benchmarks. I'm all for making httpd faster, scale better, etc. I just don't want to be extremely disappointed if we rewrite it all and gain nothing but a more complicated model. If we get great gains, wonderful, but I'd like to see some actually numbers before we all decided to rework the core. (Disclaimer: yes, I'm partially playing devil's advocate here.) -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
Akins, Brian wrote: On 9/21/08 2:17 AM, Bing Swen [EMAIL PROTECTED] wrote: But an optimal network i/o model needs a layer that maps a *request* to a thread, so that a worker thread (or process) will not have to be tied up entirely with a single connection during the whole life time of the connection. Instead, a worker can be scheduled to handle different connections, which helps both reducing the number of workers and the performance of request handling (especially on slow connections). I still want to see this backed up with real world experience. I know I keep repeating myself, but in the real world, we have never seen the supposed inherent performance problems in the worker model (1 connection = 1 thread). It sounds great to theorize about the wonders of a completely event driven or asynchronous model. However, it seems that this only nets real measurable performance gains is very simplistic benchmarks. I'm all for making httpd faster, scale better, etc. I just don't want to be extremely disappointed if we rewrite it all and gain nothing but a more complicated model. If we get great gains, wonderful, but I'd like to see some actually numbers before we all decided to rework the core. Devil's advocate or not, the point is valid IMO. We can (and likely will) have loads of fun reworking everything, but I'm +1 with Brian here. Issac
Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
Akins, Brian wrote: I'm all for making httpd faster, scale better, etc. I just don't want to be extremely disappointed if we rewrite it all and gain nothing but a more complicated model. If we get great gains, wonderful, but I'd like to see some actually numbers before we all decided to rework the core. I think the risk of being extremely disappointed is a real risk, but I don't think it is a reason not to give it a try. Perhaps a suitable compromise is to say this: - Some people want to try to come up with a purely event driven model that requires changing the MPM interface as necessary. Who knows, it might give performance gains too! - Some people want to keep an MPM that implements the worker model, because we know it works to an acceptable level. If we can achieve both at once, that will be ideal. (Disclaimer: yes, I'm partially playing devil's advocate here.) Wearing the hat of someone who likes to try out new stuff, from time to time you hit a dead end within the design of the server that makes it either hard to or impossible to achieve something new. A shake up of the core is likely to remove some of these barriers, which in turn means that avenues open up that up till now have been dead ends, which makes the development interesting again. I think the second-from-worst case scenario is that Paul and others end up exploring some cool ideas and they don't work, and then the fun was in the exploring of the new ideas, so nothing is really lost. The best case scenario is obviously that some cool ideas are explored and they do work. The worst case scenario is that people do nothing. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
Akins, Brian wrote: On 9/21/08 2:17 AM, Bing Swen [EMAIL PROTECTED] wrote: But an optimal network i/o model needs a layer that maps a *request* to a thread, so that a worker thread (or process) will not have to be tied up entirely with a single connection during the whole life time of the connection. Instead, a worker can be scheduled to handle different connections, which helps both reducing the number of workers and the performance of request handling (especially on slow connections). I still want to see this backed up with real world experience. I know I keep repeating myself, but in the real world, we have never seen the supposed inherent performance problems in the worker model (1 connection = 1 thread). At $work, we just upgraded RAM in what is essentially web server machines, just because we are running worker MPM and expect lots of long lived connections. It has a cost, and it isn't free. It sounds great to theorize about the wonders of a completely event driven or asynchronous model. However, it seems that this only nets real measurable performance gains is very simplistic benchmarks. What I view happening in the event MPM today, and where I would like to go in 2.4, isn't a fully 'asynchronous model'. It is much more of a hybrid, using threads (and processes) when running most code, but allowing requests to be moved to an event queue, waiting for IO, or a timer. I'm all for making httpd faster, scale better, etc. I just don't want to be extremely disappointed if we rewrite it all and gain nothing but a more complicated model. If we get great gains, wonderful, but I'd like to see some actually numbers before we all decided to rework the core. No, in pure requests/second, there will not be a significant difference. Today, a properly tuned apache httpd, with enough RAM, can keep up with the 'fastest' web servers of the day, like lighttpd. Most of the benchmarks where we do badly, is when apache httpd is mis-configured, or running on extremely low RAM resources. I think what we solve, is that with a slightly more async core and MPM structure, we can signfigantly reduce the memory required to service several thousand long lived connections. Moving forward with a hybrid that lets you pull in async abilities when needed seems reasonable to me. -Paul
Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
On Sep 22, 2008, at 11:51 AM, Paul Querna wrote: No, in pure requests/second, there will not be a significant difference. Today, a properly tuned apache httpd, with enough RAM, can keep up with the 'fastest' web servers of the day, like lighttpd. Most of the benchmarks where we do badly, is when apache httpd is mis- configured, or running on extremely low RAM resources. I think what we solve, is that with a slightly more async core and MPM structure, we can signfigantly reduce the memory required to service several thousand long lived connections. Agreed. We're not talking, imo, about increasing performance. We're talking increasing efficiency. Moving forward with a hybrid that lets you pull in async abilities when needed seems reasonable to me. ++1...
Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
Paul Querna [EMAIL PROTECTED] wrote on 2008-9-21 4:21 Graham Leggett wrote: I know there are likely huge problems with this, but I would like to see how far we can push the Event MPM, figure out what to do better, if there is anything, and then really dive into the 3.0 development before ApacheCon. How difficult would this be to support in the other MPMs? Windows, Worker MPM and the similar threaded MPMs could do it easily. But, IMO, I want to eliminate all of the MPMs for 2.4/3.0. I believe the MPMs as they are designed right now, are both a layer of portability, and a module that defines behavior or the model. ... Basically, one MPM to rule them all, with a configuration directive that can make it act like prefork or the event MPMs. Currently the role that MPMs play is to map a connection (with many requests, by HTTP/1.1) to a worker (a thread or process). But an optimal network i/o model needs a layer that maps a *request* to a thread, so that a worker thread (or process) will not have to be tied up entirely with a single connection during the whole life time of the connection. Instead, a worker can be scheduled to handle different connections, which helps both reducing the number of workers and the performance of request handling (especially on slow connections). Such a layer should unify the upper interface of Event driven i/o, Windows i/o completion port, and many other async i/o mechanisms. With luck and careful design, the current filtered i/o chain and the module API can remain the same. I hope that this would be one of the best features that 2.4+ will bring to us, as finally it will support any optimal i/o model on various platforms, and answer the doubts on Apache performance once and forever. Bing School of EE CS, Peking University, Beijing 100871
Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
On Sep 20, 2008, at 4:31 PM, Paul Querna wrote: Jim Jagielski wrote: On Sat, Sep 20, 2008 at 11:58:09AM -, [EMAIL PROTECTED] wrote: -#define ap_queue_empty(queue) ((queue)-nelts == 0) +#define ap_queue_empty(queue) ((queue)-nelts == 0 APR_RING_EMPTY(queue-timers ,timer_event_t, link)) Not || ? Don't think so? You want to return true if there are both zero entries in the array, and zero in the ring. And false if either has something in it. Ahhh yes, we need to check both structs in the queue now.
Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
On Sat, Sep 20, 2008 at 11:58:09AM -, [EMAIL PROTECTED] wrote:
Does anyone besides Rdiger read commit emails :-) ?
No :)
+else {
+/* X: lol, pool allocation without a context from any
thread.Yeah. Right. MPMs Suck. */
+te = malloc(sizeof(timer_event_t));
+APR_RING_ELEM_INIT(te, link);
+}
+
-#define ap_queue_empty(queue) ((queue)-nelts == 0)
+#define ap_queue_empty(queue) ((queue)-nelts == 0
APR_RING_EMPTY(queue-timers ,timer_event_t, link))
Not || ?
Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
[EMAIL PROTECTED] wrote: Using this basic framework, you can return SUSPENDED from an HTTP Handler, and then register a callback that is invoked by the MPM at a later time. This initial version only supports _timers_ as callbacks, but in the future I would like to add things like wait for socket activity, on a socket specified by the handler. Ooooh... if you extend that idea to include callbacks on files as well as on sockets, you will help solve a long standing problem in the mod_disk_cache code. It is something I have been keen to get into APR for a while (though I want to finish the current stuff on my APR plate first). Does anyone besides Rüdiger read commit emails :-) ? Afraid not. I know there are likely huge problems with this, but I would like to see how far we can push the Event MPM, figure out what to do better, if there is anything, and then really dive into the 3.0 development before ApacheCon. How difficult would this be to support in the other MPMs? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
Graham Leggett wrote: I know there are likely huge problems with this, but I would like to see how far we can push the Event MPM, figure out what to do better, if there is anything, and then really dive into the 3.0 development before ApacheCon. How difficult would this be to support in the other MPMs? Windows, Worker MPM and the similar threaded MPMs could do it easily. But, IMO, I want to eliminate all of the MPMs for 2.4/3.0. I believe the MPMs as they are designed right now, are both a layer of portability, and a module that defines behavior or the model. This makes all of the Unix ones very messy, with lots of copied code. Just look at Prefork, Worker, Event, Leader, Perchild -- they all have huge swaths of copied code. And at their cores their behavior differences could just be runtime decisions. I believe that at a minimum on the Unix side, and hopefully Win32 too, they should all be replaced with a single MPM, that has a configurable behavior, and uses APR as much as possible, with only a few small ifdefs for portability. Basically, one MPM to rule them all, with a configuration directive that can make it act like prefork or the event MPMs. -Paul
Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
Nick Kew wrote: On 20 Sep 2008, at 12:58, [EMAIL PROTECTED] wrote: Introduce Suspendable Requests to the Event MPM. Hmmm ... Are you sure this belongs in the MPM? The core problem is, where do we have an Event scheduling and worker thread system. The best place to keep that is the MPM right now -- see the future direction of MPMs thread for my thoughts on that :-)
Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
On 09/20/2008 01:58 PM, [EMAIL PROTECTED] wrote: Author: pquerna Date: Sat Sep 20 04:58:08 2008 New Revision: 697357 URL: http://svn.apache.org/viewvc?rev=697357view=rev Log: Introduce Suspendable Requests to the Event MPM. Modified: httpd/httpd/trunk/include/ap_mpm.h URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mpm.h?rev=697357r1=697356r2=697357view=diff == --- httpd/httpd/trunk/include/ap_mpm.h (original) +++ httpd/httpd/trunk/include/ap_mpm.h Sat Sep 20 04:58:08 2008 @@ -152,6 +152,14 @@ */ AP_DECLARE(apr_status_t) ap_mpm_query(int query_code, int *result); + +typedef void (ap_mpm_callback_fn_t)(void *baton); + +/* XXX: only added support in the Event MPM */ +AP_DECLARE(void) ap_mpm_register_timed_callback(apr_time_t t, +ap_mpm_callback_fn_t *cbfn, +void *baton); + This breaks compilation of other MPMs as exports is created from all prototypes found in all header files in include. So IMHO the implementation of ap_mpm_register_timed_callback either has to move to mpm_common.c or we need to add dummy implementation for the other MPM's. Or we have a dummy implementation in mpm_common.c that is in a conditional block and that only gets compiled if the MPM is not the event MPM. Regards Rüdiger
Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
Ruediger Pluem wrote: + +typedef void (ap_mpm_callback_fn_t)(void *baton); + +/* XXX: only added support in the Event MPM */ +AP_DECLARE(void) ap_mpm_register_timed_callback(apr_time_t t, +ap_mpm_callback_fn_t *cbfn, +void *baton); + This breaks compilation of other MPMs as exports is created from all prototypes found in all header files in include. So IMHO the implementation of ap_mpm_register_timed_callback either has to move to mpm_common.c or we need to add dummy implementation for the other MPM's. Or we have a dummy implementation in mpm_common.c that is in a conditional block and that only gets compiled if the MPM is not the event MPM. I'd be okay with svn delete prefork worker as a solution :-) Anyways, added a dummy version to mpm_common.c in r697425 for now. -Paul
