[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: default Content-Length calculation has been removed in 2.0 (was
From:       Stas Bekman <stas () stason ! org>
Date:       2002-11-29 9:48:49
[Download RAW message or body]


> 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...

On the opposite, IMHO this is very ON topic, since that's the core of 
the 2.0.

>>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.

That's the real pipeline. But it'll be only useful if you have many 
CPUs. I remember reading somewhere, that on a single CPU sequential 
processing might be faster rather than pseudo-parallel, because of the 
context-switch overhead. Though admittedly it's much smaller with 
threads, but depends on the implementation.

Now, nothing prevents you from developing your own mpm right now or at 
any time latter that will do what you want. It's actually much easier 
that it seems to be because a big chunk of functionality is abstacted 
away. So it's not like writing an Apache server from scratch. I admit 
that I haven't written my own mpm yet and that's the impression that I 
have from reading posts at httpd-dev.

> 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.

Yes and no. Remember that our perl interpreters live in a separate pool 
of threads, so if we can release them asap, they can go and serve more 
requests, while the filters do whatever they do. Since the perl 
interpreters don't reside on the same thread that serves the connection.

Though you are correct that the response handler won't be released until 
the filters will be done. So we need to think of some trickery to 
release the response handler earlier.

> 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?

Sure, there is nothing wrong with front/end backend setup, it just makes 
things a bit more complicated to setup and maintain. So if we can 
provide an alternative solution that requires only one server, that 
would be cool.

That's said let's worry first to get the core things working first and 
if you want to play with optimizations please go ahead and hack away :)

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

[prev in list] [next in list] [prev in thread] [next in thread]