> Issac Goldstand wrote: > > I think I got it... I was under the understanding that each fireman could > > only hande 1 bucket at a time, but there could be up to as many buckets as > > firemen on the stack at any given time... Do you know why it's like that? > > a limitation of the current mpms, there is only one thread/process for > the whole pipeline of stages (filters/handlers). You could benefit from > a real pipelining on an SMP machine. > > In any case we rather discuss this on the list. > Well, it's been getting *WAY* OT - more geared for dev@httpd if anywhere, but I'm sure they've argued this out already :-) My initial ideas all counted on the fact that each handler/filter would have a way of getting its own per-request thread...
> there is a talk about async I/O mpms for 3.0, or later 2.x > This sounds like our "many buckets with firemen" scenario - but, again, it only really becomes useful if the handlers/filters have their own thread running space. But the conclusion I'd draw from this, getting back to the original question, is that under Apache 2, it's *still* worth doing a frontend/backend setup where the frontend buffers all the backend data. Even if we *did* write the buffer filter, if the whole pipeline is stuck in one thread, then we're not freeing up the resources when the heavy handler/filter is done, so slow clients will still clog server resources. The frontend/backend solution takes care of this, because here, we're creating our own 2-threaded pipeline: the important thing being that the frontend should either have a buffer filter, or better yet, a "constant flush + buffer" filter to get the data from the backend straight to the client, while buffering additional data if needed. Does this make sense to you? Issac
