Yesterday, after realizing that my haproxy.conf selecting __ac cookie for session persistence (by setting its own cookie for backend chosen) was dooming caching of static resources by Varnish, I switched to balance hdr(x-forwarded-for). Is this the best option for sticky sessions, re: compromise between distribution (ZODB cache affinity) and downstream caching (varnish)? Thoughts?
For the record, my hosting stack is nginx->varnish->haproxy->[4xZServer]->RelStorage+PostgreSQL. I am now setting X-Cache and X-Cacheable response headers in VCL [1], and that's how I stumbled into realizing (the, in hindsight, obvious conclusion that) haproxy using cookies was a bad idea [2].
[2] There's a lot of searchable stuff out there linking to example configs using session cookies for haproxy backend selection, which looks to not jive with the plone.app.caching.strongCaching operation.
We avoid using sticky sessions balancing by not using anything that use sessions. Plone itself doesn't use sessions. Most plugins don't use sessions. I've altered plugins that do use sessions such as the patch code in collective.saml2.
Sticky sessions are just a pain.
If you really want to use sessions you can use a session storage that is shared like using beaker.
Overall I dont agree. Your assumption that we do not use sessions (I would not do it either) is right. But thats not the point.
Sticky sessions configured to optional use the __ac cookie if its there have many advantages if it comes to optimized database caches. The impact is a bit reduced if you use RelStorage with memcached. But with classical ZEO and a decent amount of logged in users its something thats speeds the single page rendering a lot in case you have larger installations such as with more than 2 zeo clients.
For primary anonymous requests it does not make much sense, except if you have a heavy multilingual site with lots of content. In this case it speeds up things if you stick to the language cookie.
HAProxy offers several options to stick to a session.
always create cookie on its own using cookie (alwaays set, bad if varnish in front)
prefix existing cookie using cookie (but afaik no way to not set it)
reuse application session cookie appsession (deprecated, do not use)
create a custom table with rules and values for stickiness stick-table/stick (full flexibility!)
In Plone you probably want to stick to the current user or the language and in almost read-only intranets maybe to the a cluster of specific users (like of one department). Otherwise do not stick but do leastconn balancing.
The only way I know to achieve this is to use a stick ... rule.