varnish-dev Digest, Vol 116, Issue 25

[Phil Stanhope]

I've not responded in awhile, but this one touches on things close to how I
use aspects of Varnish.

(This is rather long and rambling and probably mostly for Martin,
> but I'm sending it -dev in case anybody else is interested and for
> completeness of the mail-archive.)
>
>
[SNIP]

This raises the interesting question:  Should we always use a busyobj
> to fill an objcore, even for req.body and synthetic ?
>

Anything that slows down synthetic, makes me worry. I like all the benefits
that I get
for normal use cases, plus the extra boost from "clever" synthetic
services.

>
> I'm increasingly leaning that way, for reasons of code simplicity
> and symmetry.
>

But, I can see the value to the underlying system.


> Streaming on synthetic seems far out only until you start using
> weird VMODs to generate the synthetic response body slowly[1].
>

This seems counter-intuitive. But I get the [a] use case and I've used it
before.
Blackholing a requester with a very long response. But since I've got a
terminator in front of varnish
and I'm more concerned about DDoS via TLS attacks, I shifted the
blackholing to the terminator
and let varnish continue to do what it does best.

Alas, a port 80 blackhole could be just as important because my varnish
servers also respond there.
I'd not considered this before.

I'd like to discuss more in Rotterdam. I've got something that could come
in very handy in terms of managing
and accessing the "db" of prefixes for which you'd want to do something
like this. There are other related use cases
for how you might decide to blackhole at the app layer (rather than IP
filters, etc) and use the same lookup service
for other purposes.


> ...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.
>
> 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.
>
> 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.
>

A blackhole service would have, in effect infinite storage. But of course,
that doesn't happen
because of the very very slow chunking of response (e.g. byte per time
period). These are
aberrant behavior though. You'd not want the response cached because you're
really sacrifycing
a socket. Thus my desire to really implement this in front.


>
> 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.
>
> 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.
>
> Fitting the "delete while passing" case into this, is a matter of
> bookkeeping and calling the stevedores ->delete_segment method.
>
> Comments, inputs, thoughts ?
>
> Poul-Henning
>
>
> [1] Actually, it's not obvious to me that we should have the "magic"
>     path for synthetic any more, why don't we just push a synthetic
>     backend and use the regular path ?
>

I'm okay with this conceptually. Just need to understand the refactoring
necessary and the (I can only assume)
decrease in throughput for an intentionally non-caching, synthetic backend.

But ... "magic" isn't my conceptual understanding. Awhile back we talked
about separating the front-end and back-end
state machines. Synthetic living only in the front and having increased
performance as a by-product. Isn't this separation also a
source of asymmetry? There is no BERESP. There is no BERESP keep/ttl, only
the final deliver/resp. No stale serving. These
are all arguably things that support this idea and the resulting symmetry
that would come of it.


>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>
>
> ------------------------------
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
> End of varnish-dev Digest, Vol 116, Issue 25
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20151127/a0a08ea7/attachment.html>