my ideal resolution to small writes

[Greg Stein <gs...@lyra.org>]

There are two types of small writes:

1) small writes to ap_r* by legacy modules or those who don't want to learn
   the bucket API.

2) users of the bucket API that simply generate lots of little bits of data


My ideal resolution to the above two problems is to apply two separate
patches.

Problem (1):
  Use my patch to glom up the ap_r* bits into larger chunks.

Problem (2):
  Use a "tail-bucket" (need a better name :-) system that drops the little
  bits into a bucket at the end of the brigade. The little bits are always
  properly ordered (and already inserted!) into the brigade, without
  reliance on the user calling a [flush] function. Appending new buckets to
  the brigade follows standard operation, and the new bucket is properly
  sequenced after the glomming-bucket.


I would be happy to (partially!) code (2) if my textual descriptions have
not been adequate. For example, I could implement an apr_brigade_write()
that shows the mechanism.


IMPORTANT NOTE:
  By their very definition, apr_brigade_write, _printf, _putstrs, etc have
  an inherent problem dealing with large amounts of data. Consider: upon
  return from these functions, the data will "disappear." That implies the
  brigade_write function must copy the data to a heap/malloc buffer. (note
  that a transient bucket cannot be used)

  As long as the caller can *ensure* they aren't calling with large values,
  then the apr_brigade_write functions are useful. If they make a mistake
  and pass in 100k, then the app is in trouble.

  Ideally, an app that generates a 100k block will use other parts of the
  brigade/bucket API to manage data of that size.


Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: my ideal resolution to small writes

[rb...@covalent.net]

> In fact, the first thing I would do if I had the time would be to
> toss out every decision made at the "filters meeting" and
> reimplement the filters as a simple linked-list stack with statically
> allocated buckets (pointing to separately allocated bucket data).
> 
> I bet that would be popular.

It sure would be.  I have already tried it once.  The problem is that we
want to use pool cleanups to clean up the brigade.  I couldn't make this
work without leaving a gaping hole that would allow module writers to
easily create very significant memory leaks.  I would be interested in
seeing your approach.

> But, lacking the time, I'd settle for a 2.0 that works.
> Both of the proposed solutions are band-aids at best, so just
> commit whatever is better than today's HEAD and replace it later
> if it turns out to suck as well.  Commit both if that is what
> it takes.

In what sense are both solutions band-aids?  I would like an honest
opinion here.  Granted, this solution could be solved with a cleaner
set-aside function, but isn't that just a different band-aid?

> And I'd honestly appreciate it if people would stop making grandiose
> claims about freezing the API for some or such release.  The API
> isn't going to be frozen until it is proven to be stable, which
> means when the pressure to change it becomes less than the pressure
> to keep it static.  Just generate the bloody tarball and we can
> decide afterwords whether or not it is good enough to be frozen.

I don't believe I ever said anything about the API being frozen.  In fact,
we have made more sweeping API changes in the last week than I can
remember making any other time.  What I have asked for, is a feature
freeze.  We, I am as guilty as anybody, have been adding features to this
thing for years, and now we need to stop adding features and start fixing
the ones we have.  I see those two things as being VERY different beasts.

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: my ideal resolution to small writes

["Roy T. Fielding" <fi...@ebuilt.com>]

My opinion is that the only reason this is an issue at all is because
the buckets API, as currently implemented, doesn't work the way we
need it to work.  What I would do is simply put all of the coalescing
in the HTTP message filter (and have it do the chunking, rather than
split that task into a separate filter), pass the header fields
through the filter as metadata (so that things like charsets and
content lengths can be handled properly), and create a new

   ap_rwrite_brigade(r, brigade)

function that manages the interleaving of old r_w* calls with the
more efficient brigade writes.  But that would obviously take a
lot of work, and I need to find a way to keep up with e-mail first.

The fault in the current code is in the setaside design.  It should
be setting aside the content whenever the content is too small to
justify a write, and in the process collecting the content into
a large buffer rather than trying to keep the bucket structures.
But implementing that right requires a first-class ADT for buckets
and the removal of all that fricken macro crap that has spread
implementation assumptions throughout the server.

In fact, the first thing I would do if I had the time would be to
toss out every decision made at the "filters meeting" and
reimplement the filters as a simple linked-list stack with statically
allocated buckets (pointing to separately allocated bucket data).

I bet that would be popular.

But, lacking the time, I'd settle for a 2.0 that works.
Both of the proposed solutions are band-aids at best, so just
commit whatever is better than today's HEAD and replace it later
if it turns out to suck as well.  Commit both if that is what
it takes.

And I'd honestly appreciate it if people would stop making grandiose
claims about freezing the API for some or such release.  The API
isn't going to be frozen until it is proven to be stable, which
means when the pressure to change it becomes less than the pressure
to keep it static.  Just generate the bloody tarball and we can
decide afterwords whether or not it is good enough to be frozen.

....Roy

Re: my ideal resolution to small writes

[rb...@covalent.net]

> 1) small writes to ap_r* by legacy modules or those who don't want to learn
>    the bucket API.
> 
> 2) users of the bucket API that simply generate lots of little bits of data

These are the SAME problem.  Why do you want two different solutions?

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------