How to store per-session director data / VSLP director design

[Nils Goroll]

Hi,

>>> Don't you overlook the fact that the active VCL may change between
>>> two requests on the same session ?
>>
>> Hm. At this point I don't understand what I'd need to consider regarding a
>> change of the VCL.
> 
> You may not have the same VCL code, directors or backends for all requests
> on a given session.
> 
> That opens a number of cans of worms:

Thank you for the explanations.

Regarding state, I didn't plan to keep any state across requests, I hope I am
not doing this in error, and I'll check the changes regarding this aspect.

Regarding memory, so far I'm taking allocations from sp->http->ws, not knowing
of any better way within the current framework. As proposed in my OP, I favor
the idea to embed the state into struct session to avoid dynamic allocation in
the first place.

Do you have an opinion about this?

Thinking again about these aspects, for some use cases it would probably be more
efficient to cache state across requests (for the duration of a session), but
the purpose I developed this for actually does require a load
balancing/persistence decision per request anyway.

> My plan for the functionality you propose, is to add a "client.identity"
> string variable you could set in vcl_recv{} and let the client
> director operate on that string.  If the string is not set, client.ip
> will be used, like today.

Yes, I quite liked this concept, but I find it is tied too closely to the idea
of client persistence. There are two reasons why I prefer something like a "load
balancing key" (or maybe persistence key is a better name):

- Conceptually, it makes clear that persistence can be defined upon anything,
not just something client specific (the client.identity could be used anyway, sure)

- The purpose I developed this for requires that the key can be stored in the
client state (Cookie), so making hashing optional is just a natural solution to
extract it again.

> I have also pondered a scheme where we cache an opaque cookie to
> the last backend used in the session, and let directors attempt to
> use this to gain affinity, since that could provide some stability
> across a director modification (in a new VCL).

Agree. For the time being, I believe the simple solution will do, but you're
definitely right that the lack of stability is an issue as long as we don't have
a proper way to keep (and distribute) state.

I must say though that once we start talking about stateful persistence, I favor
the idea of actually distributing state across a cluster of varnish servers, for
instance by using something like memcache and to keep that also across sessions.

IMHO, storing persistency information in a cookie can only be an intermediate
solution because we can't influence load balancing of other requests to other
servers which are in flight at the same time.

> This is likely a lot less useful than you think, as many sites have
> a separate backend for images and other primitive static content.

I don't think I understand what you mean.

Poul-Henning, I really appreciate this fruitful discussion, but could I please
ask you to let me know what you think about the director session state thing?

Cheers, Nils