You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Paul J. Reder" <re...@raleigh.ibm.com> on 2001/01/12 21:55:22 UTC
Bucket/brigade re-use pool.
The previously discussed re-use pool for buckets/brigades was the next thing
that I was going to work on (before the code freeze came up). Does this count
as frozen development, or is this something I can work on?
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Bucket/brigade re-use pool.
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 01:53 PM 01/15/2001, Greg Marr wrote:
>At 01:33 PM 01/15/2001, Bill Stoddard wrote:
>> > We are in code freeze. This is not a bug, it is an optimization.
>>
>>The whole point of a beta is to detect bugs that the developers
>>miss. Performance is an essential 'feature' of Apache 2.0 and if
>>Apache 2.0 does not perform, it is a bug. If the server is
>>'destabilzed' by performance fixes, we fix them.
>
>not for the of 2.0 development.
...the rest of...
Re: Bucket/brigade re-use pool.
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 01:33 PM 01/15/2001, Bill Stoddard wrote:
> > We are in code freeze. This is not a bug, it is an optimization.
>
>The whole point of a beta is to detect bugs that the developers
>miss. Performance is an essential 'feature' of Apache 2.0 and if
>Apache 2.0 does not perform, it is a bug. If the server is
>'destabilzed' by performance fixes, we fix them.
The feature freeze was only until the first beta is released, not for
the of 2.0 development.
--
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
Re: Bucket/brigade re-use pool.
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Fri, 12 Jan 2001, Paul J. Reder wrote:
>
> > The previously discussed re-use pool for buckets/brigades was the next
thing
> > that I was going to work on (before the code freeze came up). Does this
count
> > as frozen development, or is this something I can work on?
>
> We are in code freeze. This is not a bug, it is an optimization.
The whole point of a beta is to detect bugs that the developers miss.
Performance is an essential 'feature' of Apache 2.0 and if Apache 2.0 does
not perform, it is a bug. If the server is 'destabilzed' by performance
fixes, we fix them.
Bill
Re: Bucket/brigade re-use pool.
Posted by rb...@covalent.net.
> > > The API will be with us for a long time. I am interested in getting it right before we start
> asking
> > > folks to write to it.
> >
> > Explain to me how using a pool of buckets instead of malloc/free will
> > change the API, and I will completely agree.
>
> I was commenting on your desire to hunt seg faults. Not a bad plan, but if you KNOW you need to make
> major changes, then you should make them then spend your time debugging the changed code, not the
> code you are about to throw away. That was my only point. I don't think using a pool of buckets
> instead of malloc.free will change the API. We desperately need to get rid of the malloc/frees.
Fine, if the patch gets to the list in time, we will include it in the
beta. I am not interested in holding up the beta for this however.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Bucket/brigade re-use pool.
Posted by Bill Stoddard <bi...@wstoddard.com>.
> > > Understand Dean, we aren't saying that the API couldn't be changed to work
> > > better, but people in the group have veto'ed changing the ap_r*
> > > API's. This severly ties our hands when it comes to making those
> > > functions work well with the buckets.
> >
> > Err, that's a bit disingenuous. More accurate to say that some of us maintain that we need a
> > buffered i/o API that is efficient and does not require module writers to learn how to program
to
> > the bucket API. ap_r* seemed a good place.
>
>
> It isn't disingenuous at all. We said that in order to make ap_r* work
> well with buckets, we would need to pass the bucket_brigade into
> ap_r*. We were then told that we weren't allowed to modify the API. If I
> could pass a brigade to ap_r* functions, then I could do all sorts of
> buffering that I can't do now. In fact, I plan to fix this problem by
> completely ignoring ap_r* functions, and just creating ap_brigade_*
> functions that directly map to ap_r*, except instead of passing in a
> request_rec, you will pass in a bucket_brigade. We get all the nice
> API's, but the buffering is allowed to work.
>
> BTW, I am 99% sure this will be done without modifying any existing API's,
> and adding a few new ones, to get all the functions that we currently have
> in ap_r*.
>
> > The API will be with us for a long time. I am interested in getting it right before we start
asking
> > folks to write to it.
>
> Explain to me how using a pool of buckets instead of malloc/free will
> change the API, and I will completely agree.
I was commenting on your desire to hunt seg faults. Not a bad plan, but if you KNOW you need to make
major changes, then you should make them then spend your time debugging the changed code, not the
code you are about to throw away. That was my only point. I don't think using a pool of buckets
instead of malloc.free will change the API. We desperately need to get rid of the malloc/frees.
Bill
Re: Bucket/brigade re-use pool.
Posted by rb...@covalent.net.
> > Understand Dean, we aren't saying that the API couldn't be changed to work
> > better, but people in the group have veto'ed changing the ap_r*
> > API's. This severly ties our hands when it comes to making those
> > functions work well with the buckets.
>
> Err, that's a bit disingenuous. More accurate to say that some of us maintain that we need a
> buffered i/o API that is efficient and does not require module writers to learn how to program to
> the bucket API. ap_r* seemed a good place.
It isn't disingenuous at all. We said that in order to make ap_r* work
well with buckets, we would need to pass the bucket_brigade into
ap_r*. We were then told that we weren't allowed to modify the API. If I
could pass a brigade to ap_r* functions, then I could do all sorts of
buffering that I can't do now. In fact, I plan to fix this problem by
completely ignoring ap_r* functions, and just creating ap_brigade_*
functions that directly map to ap_r*, except instead of passing in a
request_rec, you will pass in a bucket_brigade. We get all the nice
API's, but the buffering is allowed to work.
BTW, I am 99% sure this will be done without modifying any existing API's,
and adding a few new ones, to get all the functions that we currently have
in ap_r*.
> The API will be with us for a long time. I am interested in getting it right before we start asking
> folks to write to it.
Explain to me how using a pool of buckets instead of malloc/free will
change the API, and I will completely agree.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Bucket/brigade re-use pool.
Posted by Bill Stoddard <bi...@wstoddard.com>.
> > > > The previously discussed re-use pool for buckets/brigades was the next thing
> > > > that I was going to work on (before the code freeze came up). Does this count
> > > > as frozen development, or is this something I can work on?
> > >
> > > We are in code freeze. This is not a bug, it is an optimization. Feel
> > > free to work on it, but it will not be committed until after the
> > > beta. This patch takes a real chance of de-stabilizing the server, which
> > > is what we are trying to avoid. The goal here is to get the server to the
> > > point that we can get to beta.
> >
> > performance problems *are* bugs. the server *is* destablised right now,
> > it chews lots of memory, it's slow, it generates crap small packets on the
> > wire, there's no guarantee that it'll even match 1.3 performance. (and
> > that's pretty pathetic considering how poor 1.3's performance is.)
> >
> > it really irks me to see optimisation relegated to the final days in the
> > hopes that nothing was screwed up so seriously that a performance wiz
> > can't figure out some way around it without changing the API.
>
> Understand Dean, we aren't saying that the API couldn't be changed to work
> better, but people in the group have veto'ed changing the ap_r*
> API's. This severly ties our hands when it comes to making those
> functions work well with the buckets.
Err, that's a bit disingenuous. More accurate to say that some of us maintain that we need a
buffered i/o API that is efficient and does not require module writers to learn how to program to
the bucket API. ap_r* seemed a good place.
>
> Also, the change that Paul is talking about is just going to keep us from
> malloc'ing and free'ing buckets, just to create new ones. Yes this is a
> simple optimization that will improve our performance a bit. It is also
> not something that will require an API change, and it isn't something that
> must be done before the beta. I am much more interested in finding a few
> more seg faults, than in potentially introducing new ones right now.
The API will be with us for a long time. I am interested in getting it right before we start asking
folks to write to it.
Bill
Re: Bucket/brigade re-use pool.
Posted by rb...@covalent.net.
> > > The previously discussed re-use pool for buckets/brigades was the next thing
> > > that I was going to work on (before the code freeze came up). Does this count
> > > as frozen development, or is this something I can work on?
> >
> > We are in code freeze. This is not a bug, it is an optimization. Feel
> > free to work on it, but it will not be committed until after the
> > beta. This patch takes a real chance of de-stabilizing the server, which
> > is what we are trying to avoid. The goal here is to get the server to the
> > point that we can get to beta.
>
> performance problems *are* bugs. the server *is* destablised right now,
> it chews lots of memory, it's slow, it generates crap small packets on the
> wire, there's no guarantee that it'll even match 1.3 performance. (and
> that's pretty pathetic considering how poor 1.3's performance is.)
>
> it really irks me to see optimisation relegated to the final days in the
> hopes that nothing was screwed up so seriously that a performance wiz
> can't figure out some way around it without changing the API.
Understand Dean, we aren't saying that the API couldn't be changed to work
better, but people in the group have veto'ed changing the ap_r*
API's. This severly ties our hands when it comes to making those
functions work well with the buckets.
Also, the change that Paul is talking about is just going to keep us from
malloc'ing and free'ing buckets, just to create new ones. Yes this is a
simple optimization that will improve our performance a bit. It is also
not something that will require an API change, and it isn't something that
must be done before the beta. I am much more interested in finding a few
more seg faults, than in potentially introducing new ones right now.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Bucket/brigade re-use pool.
Posted by dean gaudet <dg...@arctic.org>.
On Fri, 12 Jan 2001 rbb@covalent.net wrote:
> On Fri, 12 Jan 2001, Paul J. Reder wrote:
>
> > The previously discussed re-use pool for buckets/brigades was the next thing
> > that I was going to work on (before the code freeze came up). Does this count
> > as frozen development, or is this something I can work on?
>
> We are in code freeze. This is not a bug, it is an optimization. Feel
> free to work on it, but it will not be committed until after the
> beta. This patch takes a real chance of de-stabilizing the server, which
> is what we are trying to avoid. The goal here is to get the server to the
> point that we can get to beta.
performance problems *are* bugs. the server *is* destablised right now,
it chews lots of memory, it's slow, it generates crap small packets on the
wire, there's no guarantee that it'll even match 1.3 performance. (and
that's pretty pathetic considering how poor 1.3's performance is.)
it really irks me to see optimisation relegated to the final days in the
hopes that nothing was screwed up so seriously that a performance wiz
can't figure out some way around it without changing the API.
-dean
Re: Bucket/brigade re-use pool.
Posted by rb...@covalent.net.
On Fri, 12 Jan 2001, Paul J. Reder wrote:
> The previously discussed re-use pool for buckets/brigades was the next thing
> that I was going to work on (before the code freeze came up). Does this count
> as frozen development, or is this something I can work on?
We are in code freeze. This is not a bug, it is an optimization. Feel
free to work on it, but it will not be committed until after the
beta. This patch takes a real chance of de-stabilizing the server, which
is what we are trying to avoid. The goal here is to get the server to the
point that we can get to beta.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------