auto-tune ws / headroom poc
slink at schokola.de
Wed Feb 1 17:14:40 CET 2017
this just surfaced again. More than before I think we should not let the admin
size workspaces, but just the space available to VCL.
On 29/02/16 13:49, Nils Goroll wrote:
> following up an attempt to discuss this on irc:
> The following discussion is, for the time being, regarding workpace_backend
> only, but the question is relevant for the other workspaces also:
> Relevant portions of workspace_backend are not available for use in VCL, but are
> consumed in core code. Setting workspace_backend too low will trigger an
> immediate assertion failure in VBO_GetBusyObj().
> IMHO, it doesn't make sense to handle these assertions differently, because
> space for http headers, vsl and the initial read from the backend are mandatory
> for varnish to issue backend requests.
> Instead of trying to better handle nonsense workspace_backend sizes, I'd suggest
> to make it impossible to tune it stupidly in the first place - and to give
> admins a tunable which is easier to understand.
> The attached patch contains a PoC (this is _not_ a finished patch, see below)
> suggesting the following changes:
> - make workspace_backend a protected (read-only) parameter
> - add headroom_backend as a new admin-tunable parameter which roughly equals to
> "workspace available to VCL"
> - calculate the size of workspace_backend based on all other relevant parameters
> Notes on the patch:
> - I've kept the workspace parameter as protected so the mempool code can stay
> as is (pointing to a single parameter for sizing)
> - in VBO_Init() I've taken a lightweight approach at the consistency issue from
> parameter changes, and I'd be curious to hear if others agree or think
> that we need to make this safer.
> - what is the best way to cross the border between the cache and mgt code?
> Originally I would have preferred to have the sizing code in cache_busyobj.c,
> but then we'd need to make mgt_param visible there - which I didn't like.
> But what I have in the patch now doesn't look clean at all, I am really
> unsure at this point.
> Thx, Nils
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
More information about the varnish-dev