apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: stupid bucket tricks
Date Thu, 27 Sep 2001 04:18:54 GMT
On Wednesday 26 September 2001 08:40 pm, Cliff Woolley wrote:
> Does anyone have a sense of how long a string would have to be before
> this:
>     str = apr_psprintf(p,
> "</PRE>\n\n<HR></HR>\n\n%s\n\n</BODY>\n</HTML>\n", ap_psignature("",
>     e = apr_bucket_pool_create(str, strlen(str), p);
> got to be significantly more expensive than this?
>     e = apr_bucket_immortal_create("</PRE>\n\n<HR></HR>\n\n", len1);
>     str = ap_psignature("", r);
>     e = apr_bucket_pool_create(str, strlen(str), r->pool);
>     e = apr_bucket_immortal_create("\n\n</BODY>\n</HTML>\n", len2);
> I guess a big part of that question is "how expensive is apr_psprintf?"
> Furthermore, at what point does splitting the thing into a bunch of little
> bitty bucket meatballs (as with the second option here) become a loss in
> terms of bucket processing overhead later on?
> I don't really expect anyone to have the answers to these questions, I
> just thought I'd throw them out there anyway.
> [In case anyone's curious, the first option here came straight from
> mod_proxy... I just made up the second version as food for thought.]

It's almost impossible to answer this question, there are too many variables.

1)  How much is already in the last bucket in the brigade?  apr_brigade_printf
writes directly to the bucket, but if the bucket has more than 9K (I think that's
the value), it triggers a flush.  If the last bucket doesn't exist, we need to allocate

2)  What are the other buckets in the brigade in case 2?  When we go to send
the data, we play some tricks to make sure that we send a lot of data in each
packet.  This means that we can end up copying to combine buckets.  But,
if the other buckets are big enough, we will just use writev or sendfile.

In general, option 1 caused a malloc for the bucket, a heap bucket, and 9K of data
for the heap bucket.  We also memcpy the data into that bucket.

In option 2, 3 buckets, 2 immortal buckets, and 1 pool bucket.  Then we do
some simple pointer assignment.

Option 2 should always be less expensive than 1, because we allocate less 
memory, although we have end up making more malloc calls.  If the OS has a 
good malloc implementation though, that won't hurt us too much. 

Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message