httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Counting of I/O bytes
Date Wed, 16 Oct 2002 14:36:11 GMT
At 02:10 AM 10/16/2002, Bojan Smojver wrote:

>Coming back to what William is proposing, the three pool approach... I'm
>guessing that with Response put in-between Connection and Request, the Response will store
responses for multiple requests, right?

No, I'm suggesting a single response pool for each request.  As soon as
the request is processed, the request pool disappears (although some 
body may still sitting in brigades, or set aside within filters).  As soon as
the body for -that- request- has been flushed complete, that response
pool will disappear.

Since this isn't too clear by the names, perhaps 'connection', 'request'
and an outer 'handler' pool make things more clear?  In that case, the
handler pool would disappear at once when the response body had been
constructed, and the 'request' pool would disappear once it was flushed.

> Then, once the core-filter is
>done with it, the Response will be notified, it will finalise the processing
>(e.g. log all the requests) and destroy itself. Sounds good, but maybe we should just
keep the requests around until they have been dealt with?

Consider pipelining.  You can't start keeping 25 requests hanging around
for 1 page + 24 images now, can you?  The memory footprint would soar
through the roof.

>BTW, is there are way in 2.0 to force every request to be written to the network
>in order? Maybe I should focus on making an option like that in order to make it
>work in 2.0?

How do you mean?  Everything to the network is serialized.  What is out
of order today, date stamps in the access logs? That is because it takes
different amounts of time to handle different sorts of requests, availability
from kernel disk cache of the pages, etc.


View raw message