Re: default Content-Length calculation has been removed in 2.0 (was Re: mod_perl 2.x vs. mod_perl 1.x benchmarks)
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
Re: default Content-Length calculation has been removed in 2.0 (was Re: mod_perl 2.x vs. mod_perl 1.x benchmarks)
- Original Message - From: Stas Bekman [EMAIL PROTECTED] Cc: Ask Bjoern Hansen [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 11:07 AM Subject: default Content-Length calculation has been removed in 2.0 (was Re: mod_perl 2.x vs. mod_perl 1.x benchmarks) Actually, returning to Issac's question regarding releasing the handler early, you need a slightly modified version of the cl filter to do that. Since it's already buffering the data, you just want to do this unconditionaly. How do you mean unconditionaly? BTW: I'm wondering whether the solutnio for the whole buffering thing is write a buffer filter or is this something that should be done internally within the brigades? After all, once the [mod_perl] response handler (or filter) passes the EOS bucket, it's not needed anymore, and who cares if the other filters are ready or not? Stas, it sounded to me like you were suggesting something like: mod_perl handler/filter---Filter API---buffer filtercore-outputclient The assumption is that if bufer_filter slurps up the data, it will release the previous filters' resources, but I think that's kinda backwards thinking. As far as I understand, the only buffer you EVER have to worry about is the data coming IN to your filter. Once you pass the buckets along, you never have to worry about them again. 2 conclusions on this (my thought process included :-)): 1) The seemingly correct thing to do here would be to ensure that a handler/filter's resource pool (and entire thread?) is cleaned up as soon as it's done running. I think the latter is true, and to do this properly, Apache'd really have to give each filter plugged into each request it's own running thread. That's gonna add lotsa overhead. Maybe just a flag to request it's own thread if the module author/user is expecting their handler/filter to really use heavy resources (like an on-the-fly image processing filter for example). That way, heavy modules can get their own resources for when their eneded and release them ASAP. 2) The flipside of this is that a heavy module (like discussed above) *would* need this buffer filter; but it would want the buffer to slurp up the data coming *in*. The idea would be to let these heavy modules *create* themselves only when the data is ready (to optimize resource allocation/usage). The problem with this is that it's useless. Each request, as I understand, requires each filter in the chain to register itself in the bucket brigade chain right at the offset - which means that the private thread idea can't work since it will have to create the thread at the beginning of the request anyway - certainly before the data is ready. Comments? Issac
