<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 26 November 2015 at 11:31, Poul-Henning Kamp <span dir="ltr"><<a href="mailto:phk@phk.freebsd.dk" target="_blank">phk@phk.freebsd.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A stevedore can override the Obj methods, but only at the cost of<br>
replicating all the rather incestuous objcore/busyobj code which<br>
makes streaming work.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That code is highly irregular, for instance ObjIter knows about<br>
busyobj, but ObjExtend() does not etc.<br>
<br>
I don't want to see the necessary logic for busyobj/streaming<br>
replicated in all advanced stevedores, so the present API will<br>
not do.<br>
<br>
This raises the interesting question:  Should we always use a busyobj<br>
to fill an objcore, even for req.body and synthetic ?<br>
<br>
I'm increasingly leaning that way, for reasons of code simplicity<br>
and symmetry.<br></blockquote><div><br></div><div>I agree that that would be a good next step.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...so assume for a moment we always use a busyobj and the streaming<br>
mechanism to fill objcores.<br>
<br>
As long as the busyobj is assembling the objcore, *all* the Obj->methods<br>
go to the busyobj's method set, and the busyobj methods call the<br>
stevedores methods to get things done.</blockquote><div> </div><div>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?</div><div> </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Once the busyobj is done, it calls the stevedore with a "commit"<br>
method and once that returns, all future Obj->methods go directly<br>
to the stevedore. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
... Except the ObjIter()s which were already running, we cannot<br>
allow the stevedore to rip storage out or move it under them,<br>
and they have to finish in the busyobj state.<br></blockquote><div> </div><div>More or less like we do it now right?</div><div><br></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I can imagine three stevedore stragegies:<br>
<br>
1. Can do Trim in place, so allocates final storage right away<br>
   and trims last segment when we know it.<br>
<br>
2. Allocates temp space for each segment, moves into final storage<br>
   when it is full/finished.<br>
<br>
3. Allocates all segments in temp space, and moves them all into<br>
   final storage only when object is finished.<br>
<br>
But I'm going to deny #3, because the performance difference between<br>
#2 with "large enough" segments and #3 is not relevant.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>If the temp space is not available to clients, then that fits with my #2 below.</div><div> </div><div><br></div><div>I believe a more useful way to look at the stevedore capabilities is:</div><div><br></div><div>1. Can provide memory pointer to final storage location, allowing the fetch processor to fetch directly into the final storage.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So the stevedore gets to pick between strategy #1 and #2 for each<br>
object.  The decision, and the #2 segment size, might be based on<br>
knowing the length from C-L or having an estimate from objhdr.<br>
<br>
This means we have at most one "uncommitted" segment at any time,<br>
and if we let the busyobj own that one (from Transient), the ObjIter<br>
issue is manageable.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Fitting the "delete while passing" case into this, is a matter of<br>
bookkeeping and calling the stevedores ->delete_segment method.<br></blockquote><div><br></div><div><br></div><div>-Martin </div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div><table border="0" cellpadding="0" cellspacing="0" style="font-size:12px;line-height:1.5em;font-family:'Helvetica Neue',Arial,sans-serif;color:rgb(102,102,102);width:550px;border-top-width:1px;border-top-style:solid;border-top-color:rgb(238,238,238);border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);margin-top:20px;padding-top:5px;padding-bottom:5px"><tbody><tr><td width="100"><a href="http://varnish-software.com" target="_blank"><img src="http://www.varnish-software.com/static/media/logo-email.png"></a><span></span><span></span></td><td><strong style="font-size:14px;color:rgb(34,34,34)">Martin Blix Grydeland</strong><br>Senior Developer | Varnish Software AS<br>Mobile: +47 992 74 756<br><span style="font-weight:bold">We Make Websites Fly!</span></td></tr></tbody></table></div></div></div></div>
</div></div>