Re: calling for a new workspace sizing concept - Re: auto-tune ws / headroom poc

[Federico Schwindt]

I prefer less knobs so I'm inclined to agree with Dridi's suggestion.

I'd propose to make the math but keep the final workspaces' numbers as they
are and bump them after the release.

That would keep the footprint similar to what it is today and we could
document the change in advance (and warn about the bump).


On Tue, Jan 30, 2018 at 1:18 PM, Poul-Henning Kamp 
wrote:

> 
>
> Let me just lay down a ground rule here:
>
> 1. I think this is an important thing to (re)consider, by all means
>go at it.
>
> 2. No commits related to this until after march 15th,.
>
> Poul-Henning
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@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@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: calling for a new workspace sizing concept - Re: auto-tune ws / headroom poc

[Poul-Henning Kamp]

Let me just lay down a ground rule here:

1. I think this is an important thing to (re)consider, by all means
   go at it.

2. No commits related to this until after march 15th,.

Poul-Henning
-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@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@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: calling for a new workspace sizing concept - Re: auto-tune ws / headroom poc

[Dridi Boukelmoune]

On Tue, Jan 30, 2018 at 2:11 PM, Nils Goroll  wrote:
> On 30/01/18 14:08, Dridi Boukelmoune wrote:
>> Instead to new xxx_headroom knobs, why not recycle the existing workspace_xxx
>> parameters to take their values _in addition to_ related parameters and maybe
>> document it as such?
>
> I wouldn't oppose to this option, but this would lead to a significant 
> increase
> of actual workspace sizes for those users who are unaware of the change.

Agreed, but in both cases we'd need to change our defaults to match
the change and users should read release notes before upgrading :)

> Using new parameter names and making the old ones read-only would raise
> awareness for the change.
>
> My preference would be the latter, but I'm ok with the former if we reach 
> consensus.
>
> Nils
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: calling for a new workspace sizing concept - Re: auto-tune ws / headroom poc

[Nils Goroll]

On 30/01/18 14:08, Dridi Boukelmoune wrote:
> Instead to new xxx_headroom knobs, why not recycle the existing workspace_xxx
> parameters to take their values _in addition to_ related parameters and maybe
> document it as such?

I wouldn't oppose to this option, but this would lead to a significant increase
of actual workspace sizes for those users who are unaware of the change.

Using new parameter names and making the old ones read-only would raise
awareness for the change.

My preference would be the latter, but I'm ok with the former if we reach 
consensus.

Nils
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: calling for a new workspace sizing concept - Re: auto-tune ws / headroom poc

[Dridi Boukelmoune]

On Tue, Jan 30, 2018 at 12:17 PM, Nils Goroll  wrote:

> * forbid any nested sizing parameters as in "if you tune knob a, you also need
>   to tune knob b" -> knob b should be replaced by a knob b' which is 
> independent
>   of knob a and any derivation should be calculated automatically.
>
> * make workspace sizes read only parameters which users can query to estimate
>   their memory consumption
>
> * replace the workspace tunables with xxx_headroom tuning just the space
>   to remain available on the workspace after deduction of all known 
> allocations

Hi,

Instead to new xxx_headroom knobs, why not recycle the existing workspace_xxx
parameters to take their values _in addition to_ related parameters and maybe
document it as such?

This way the description could tell that workspace_client is the space allocated
to VCL processing on the client side, and possibly (would we need to?) mention
that the total workspace size of a client transaction is "this much".

Knowing the formula would help capacity planning, so documenting it somewhere
sounds sensible all things considered.

I overall agree that we should prevent users from getting a configuration that
guarantees transactions failures.

Dridi
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev