You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/07/06 22:08:29 UTC
Removing C-L filter when C-L is known was Re: conserving file descriptors vs. ap_save_brigade()
On Sat, Jul 06, 2002 at 12:09:40PM -0700, Ryan Bloom wrote:
> Pay attention to what that message says please. It says "The filter
> should always be in the stack, and it should always collect
> information." It doesn't say "The filter should always be touching the
> C-L for the response." We use the data collected by the c-L filter in
> other places, so we should always try to compute the C-L in the filter.
> However, we should NEVER buffer unless we absolutely have to.
What data is it collecting? r->bytes_sent? We already know what
that value will be as it will be identical to the C-L.
To make it concrete as to what I have been suggesting in
ap_content_length_filter:
if (!ctx) { /* first time through */
char *c;
c = apr_table_get(r->headers_out, "Content-Length");
if (c) { /* Known content length. */
/* Can we rely on r->clength being valid? Perhaps because of
* ap_set_content_length's implementation. If not, we'd have
* to convert the c value to an off_t.
*/
r->bytes_sent += r->clength;
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, b);
}
f->ctx = ctx = apr_pcalloc(r->pool, sizeof(struct content_length_ctx));
...rest of ap_content_length_filter unchanged...
Does this make it any clearer? The side effect r->bytes_sent is
still maintained and the common case becomes a lot faster and we
don't bother to read any of the buckets. -- justin
Re: Removing C-L filter when C-L is known was Re: conserving file
descriptors vs. ap_save_brigade()
Posted by Brian Pane <bp...@pacbell.net>.
Justin Erenkrantz wrote:
>On Sat, Jul 06, 2002 at 12:09:40PM -0700, Ryan Bloom wrote:
>
>
>>Pay attention to what that message says please. It says "The filter
>>should always be in the stack, and it should always collect
>>information." It doesn't say "The filter should always be touching the
>>C-L for the response." We use the data collected by the c-L filter in
>>other places, so we should always try to compute the C-L in the filter.
>>However, we should NEVER buffer unless we absolutely have to.
>>
>>
>
>What data is it collecting? r->bytes_sent? We already know what
>that value will be as it will be identical to the C-L.
>
>To make it concrete as to what I have been suggesting in
>ap_content_length_filter:
>
>if (!ctx) { /* first time through */
> char *c;
> c = apr_table_get(r->headers_out, "Content-Length");
>
This won't help us much: in all the cases where the ap_save_brigade()
in the C-L filter is a performance problem (e.g., the pipe and SSI
examples), we're not going to have a C-L in r->headers_out.
And this change will slow down the server, by adding another call to
apr_table_get(), which we already know is a performance problem.
--Brian