objcore/req symmetry and Obj->methods

[Martin Blix Grydeland]

On 26 November 2015 at 11:31, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> A stevedore can override the Obj methods, but only at the cost of
> replicating all the rather incestuous objcore/busyobj code which
> makes streaming work.


> That code is highly irregular, for instance ObjIter knows about
> busyobj, but ObjExtend() does not etc.
>
> I don't want to see the necessary logic for busyobj/streaming
> replicated in all advanced stevedores, so the present API will
> not do.
>
> This raises the interesting question:  Should we always use a busyobj
> to fill an objcore, even for req.body and synthetic ?
>
> I'm increasingly leaning that way, for reasons of code simplicity
> and symmetry.
>

I agree that that would be a good next step.


> ...so assume for a moment we always use a busyobj and the streaming
> mechanism to fill objcores.
>
> As long as the busyobj is assembling the objcore, *all* the Obj->methods
> go to the busyobj's method set, and the busyobj methods call the
> stevedores methods to get things done.


What kind stevedore interface are you looking at here? An iterator approach
like the current one, only with the busyobj method methods wrapped around
enforcing the limits the stream synchronization sets?



Once the busyobj is done, it calls the stevedore with a "commit"
> method and once that returns, all future Obj->methods go directly
> to the stevedore.


> ... Except the ObjIter()s which were already running, we cannot
> allow the stevedore to rip storage out or move it under them,
> and they have to finish in the busyobj state.
>

More or less like we do it now right?



I can imagine three stevedore stragegies:
>
> 1. Can do Trim in place, so allocates final storage right away
>    and trims last segment when we know it.
>
> 2. Allocates temp space for each segment, moves into final storage
>    when it is full/finished.
>
> 3. Allocates all segments in temp space, and moves them all into
>    final storage only when object is finished.
>
> But I'm going to deny #3, because the performance difference between
> #2 with "large enough" segments and #3 is not relevant.
>

I am uncertain what you mean here. For #2, would the general busyobj
methods expect to be able to serve content the stevedore has put in temp
space to the streaming clients? Or will only final storage segments be
available to client consumption?

If the temp space is also available to the clients, I will argue that for a
sufficiently popular object #2 and #3 are the same. Given enough clients
there will be enough slow clients touching on the temp spaces preventing
them to be released, and both the temp spaces and the final storage space
would eat up memory resources.

If the temp space is not available to clients, then that fits with my #2
below.


I believe a more useful way to look at the stevedore capabilities is:

1. Can provide memory pointer to final storage location, allowing the fetch
processor to fetch directly into the final storage.

2. Can not provide memory pointer to final storage location. Busyobj would
need to have a buffer to fetch into, and pushes the buffered content to the
stevedores either when it's full or on a short read (socket read buffer
empty, slow backend). Streaming will then be delayed by up to the buffer
size.


> So the stevedore gets to pick between strategy #1 and #2 for each
> object.  The decision, and the #2 segment size, might be based on
> knowing the length from C-L or having an estimate from objhdr.
>
> This means we have at most one "uncommitted" segment at any time,
> and if we let the busyobj own that one (from Transient), the ObjIter
> issue is manageable.
>

I guess this wouldn't be Transiet, as Transient is a stevedore that might
not support that operation. I read this as the busyobj buffer above.


>
> Fitting the "delete while passing" case into this, is a matter of
> bookkeeping and calling the stevedores ->delete_segment method.
>


-Martin

-- 
<http://varnish-software.com>*Martin Blix Grydeland*
Senior Developer | Varnish Software AS
Mobile: +47 992 74 756
We Make Websites Fly!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20151130/9ff823a7/attachment.html>