Questions on backend allocations

Dridi Boukelmoune dridi at varni.sh
Fri Jun 12 11:28:07 CEST 2015


Hi,

I will try to wrap up the model I was suggesting on IRC.

For starters, I refer to dynamic backends as *native* backends (ones
you can see in varnishstat) managed by a VMOD instead of VCL.

We agreed that even though a VMOD lifespan can exceed the lifespan of
a VCL, a dynamic backend cannot survive its VCL. For this reason I
find VCL objects compelling for VMOD writers, because VMODs merely
allocate/free objects, while VCLs manage/use them.

One wouldn't be required to tie dynamic backends to an object, but
they would have to keep track of the per-VCL resources themselves.

For cold/warm state, I'm all for passing the events to VMODs (if the
event specifies which VCL is sending the event) or even better to
objects (since they *are* managed by a VCL).

Allowing VMODs to follow the cold/warm state on their own resources
is interesting[1].

Putting all this together:
- VCLs own static backends
- VMODs should own dynamic backends
- Objects are the best candidates to manage dynamic backends
- VCLs should only send events to things it manages:
  static resources, objects (not sure about VMODs)
- VMODs *can* propagate events to backends

Of course the last bullet point means more work for VMOD writers, but
in most cases it's probably just walking a data structure and forwarding
the event to each item.

It also has the advantage of not introducing order issues, and allowing
VMODs to override the VCL warm/cold state policy.

The first bullet point on the other hand means only *minor* modifications
are needed in Varnish to enable that.

Best Regards,
Dridi

[1] but what happens on vmod_tour, stays on vmod_tour

On Thu, Jun 11, 2015 at 11:16 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> --------
>
> I've been pop'ing stack and come back down to this old topic.



More information about the varnish-dev mailing list