httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: ap_r* performance patch
Date Tue, 23 Jan 2001 01:37:05 GMT
On Mon, Jan 22, 2001 at 04:42:12PM -0800, wrote:
> If I missed anybody, please stand up.  I would really like to call this a
> vote at 8:00 PM PCT.  That is about 3hr 20m from now.  We have been
> holding this vote since last thursday or friday, so it is time we made a
> decision already.  If anybody thinkgs I should wait longer, I am perfectly
> willing to wait until tomorrow morning at 7:00am, or suggest a different
> time.

Your patch needs to solve these things first:

1) ordering

2) large writes in ap_rputs, ap_rvputs, ap_rwrite, and ap_vrprintf
   specifically: how will you avoid copying the content into the brigade?

You've said (1) is possible (and you provided the "how") but don't want to
do it that way. I agree that calling apr_brigade_flush() inside the brigade
macros is bogus. I've also described the tail-bucket approach that will
completely eliminate the apr_brigade_flush() problem. If you switch to that,
it will completely remove the necessity for brigade_flush.
[ it *does* leave the ap_sync_output issue to deal with, tho; I don't have
  an answer for that one except to provide my patch. ]

I suspect that when you go to solve (2), the ap_r* functions are going to
get quite a bit hairier, and the solution to those will be Apache specific
-- exactly what you are lobbying your patch avoids.

Your solutions for the above two problems are needed before applying your
patch. I don't understand how you intend to solve them; my own thoughts on
how to do it within your framework lead me to believe that your patch won't
be as confined to APR as you believe.

Application of either patch should be held until the solution is evident.


Greg Stein,

View raw message