Mailing List Archive

Paper to think about...
http://neverworkintheory.org/2016/06/09/too-many-knobs.html

Interesting...

Maybe we should weed out some parameters for 5.0...

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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: Paper to think about... [ In reply to ]
Only a handful params actually need changing from site to site.
There are a dusin params that I've neer seen anyone use to any good
effect.. in particular, most of the ones labeled "NB: We do not know
yet if it is a good idea to change this" are voodoo for users.

On the other hand, I was thinking how does language-as-config relate
to the too-many-knobs effect? Language constructs aren't knobs per se;
they let the (literate) user write their own desired system behavior,
but forces them to invest in a steep learning curve. So it's either
not-a-knob or infinite-knobs...

On Fri, Jun 10, 2016 at 2:07 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> http://neverworkintheory.org/2016/06/09/too-many-knobs.html
>
> Interesting...
>
> Maybe we should weed out some parameters for 5.0...
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk@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



--
http://comotion.delta9.pl
http://u.delta9.pl
http://kacper.doesntexist.org
Too much order is its own chaos.
Employ no technique to gain supreme enlightment.

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
Re: Paper to think about... [ In reply to ]
On Wed, Jun 15, 2016 at 1:29 AM, Kacper Wysocki <kacperw@gmail.com> wrote:
> Only a handful params actually need changing from site to site.
> There are a dusin params that I've neer seen anyone use to any good
> effect.. in particular, most of the ones labeled "NB: We do not know
> yet if it is a good idea to change this" are voodoo for users.

In this case the varnish-cli could be changed so that experimental params
don't show up by default with `param.show -l`, requiring a new flag like -x for
instance.

That would be one more knob, but to hide less common knobs. Experimental
flags could be moved to the varnish-cli(7) manual too, in my experience most
people don't read it, only really advanced users.

> On the other hand, I was thinking how does language-as-config relate
> to the too-many-knobs effect? Language constructs aren't knobs per se;
> they let the (literate) user write their own desired system behavior,
> but forces them to invest in a steep learning curve. So it's either
> not-a-knob or infinite-knobs...

One could argue that there are too many steps in VCL. For instance, do
we really need a `sub vcl_fini{}` when VMODs could always be responsible
for cleaning up state? I don't know, but haven't seen it used so far.

The two knobs I'd remove from VCL are /* C style */ and // C++ style
comments. The remaining one would be the same between vcl and vtc files
and has a scripting language feel that fits better IMHO.

Dridi

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
Re: Paper to think about... [ In reply to ]
On 15/06/16 09:48, Dridi Boukelmoune wrote:
> varnish-cli could be changed so that experimental params
> don't show up by default with `param.show -l`, requiring a new flag like -x for
> instance.

I like this idea. So we'd have

- user tunables
- expert tunables

- param.show : show user tunables and non-default expert tunables
- param.show -x : show all

- same for -l, but full info

Having the knobs can safe your live for edge cases, and not having them built in
helps us (devs + poweruser) find the right values - so removing them does not
sound like a good idea to me.

Nils

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
Re: Paper to think about... [ In reply to ]
On Wed, Jun 15, 2016 at 10:35 AM, Nils Goroll <slink@schokola.de> wrote:

> On 15/06/16 09:48, Dridi Boukelmoune wrote:
> > varnish-cli could be changed so that experimental params
> > don't show up by default with `param.show -l`, requiring a new flag like
> -x for
> > instance.
>
>
People tend to think the expert stuff is more powerful, and that they are
entitled to it.

I would drop the ones labeled "NB: We do not know..." and only enabled them
with a compile flag and make it very clear that the plan is to drop them
unless there's a relevant use case.

I vote against the comment changes, we would unnecessarily break VCL for
very little gain.

--
Guillaume Quintard
Re: Paper to think about... [ In reply to ]
On 15/06/16 10:50, Guillaume Quintard wrote:
>
> On 15/06/16 09:48, Dridi Boukelmoune wrote:
> > varnish-cli could be changed so that experimental params
> > don't show up by default with `param.show -l`, requiring a new flag like -x for
> > instance.
>
> People tend to think the expert stuff is more powerful, and that they
> are entitled to it.
>
> I would drop the ones labeled "NB: We do not know..." and only enabled
> them with a compile flag and make it very clear that the plan is to drop
> them unless there's a relevant use case.

I vote for the classification into expert- and non-expert-level params,
and very strongly against removing any of them for no other reason than
having fewer of them.

My experience with this sort of thing is that we can all agree that
there can fewer config options, and that we will never agree on which of
them, specifically, can be eliminated.

I can name many params whose relevance seems inconceivable, to me, but
to many of you, the idea of removing some of my candidates will be
horrifying. You'll think I'm out of my mind. However we go about it, for
someone somewhere the impact will be very painful.

"NB: We do not know..." means just that -- we don't know. Probably the
vast majority of those have little impact on how Varnish works, but I'll
bet a beer at VDD that some of us have discovered a few that can make a
real difference. If we really mean it when we say we don't know, then a
blanket assumption that they all can be removed is clearly not warranted.

Version changes usually mean that certain params really do become
obsolete, that's normal. Documenting the typically important ones should
go a long way toward helping less experienced users. But swinging an axe
just to have fewer params is IMO the road to madness.

> I vote against the comment changes, we would unnecessarily break VCL for
> very little gain.

Agreed.


CU in AMS,
Geoff
--
UPLEX Systemoptimierung
Scheffelstraße 32
22301 Hamburg
http://uplex.de/
Mob: +49-176-63690917
Re: Paper to think about... [ In reply to ]
On Wed, Jun 15, 2016 at 11:31 AM, Geoff Simmons <geoff@uplex.de> wrote:


> I vote for the classification into expert- and non-expert-level params,
> and very strongly against removing any of them for no other reason than
> having fewer of them.
>

How do you feel about making a few more of them compile time options? This
would reduce the apparent number of parameters that will confuse the
bit-twidlers, shorten the docs and hopefully make people invest more time
and effort in figuring out the remaining parameters.

--
*Per Buer*
CTO | Varnish Software AS
Cell: +47 95839117
We Make Websites Fly!
www.varnish-software.com
<http://info.varnish-software.com/signature>
Re: Paper to think about... [ In reply to ]
>> I vote for the classification into expert- and non-expert-level params,
>> and very strongly against removing any of them for no other reason than
>> having fewer of them.
>
>
> How do you feel about making a few more of them compile time options? This would reduce the apparent number of parameters that will confuse the bit-twidlers, shorten the docs and hopefully make people invest more time and effort in figuring out the remaining parameters.

The great thing about `param.set` is that we can do it at run time. If
we take the very extreme end of the expert spectrum, one can have
auto-tuning in place depending on monitoring of some sort.

From a less extreme PoV, tweaking a parameter would mean having to
recompile, reinstall and restart Varnish. Tweaking becomes a show
stopper if that means such long feedback cycles. It may take time to
put the system back into a measurable state, and it means that you
can't safely tune your production without losing your cache for every
single tweak.

Dridi

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
Re: Paper to think about... [ In reply to ]
--------
In message <CAOXZevDWEZz2__qGu9fLB6JJCUp_OmqLjLOtrRZtFFTpVSJXJQ@mail.gmail.com>
, Per Buer writes:

>How do you feel about making a few more of them compile time options?

There is not really any point in making them compile time options if we
just as easily can make them runtime options.

In particular the infrastructure for documenting param.set is much better
than for compile time params.

The VDD sort-of-consensus was to have two or maybe three levels of
param.*

* no options:
workspaces, timeouts, thread-pool + other often used params
preferably not enough to scroll out of typical windows
* -d
debug/developer params
* -something (-x for expert ?)
all non-wizard params
* -a
all params


--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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: Paper to think about... [ In reply to ]
> The VDD sort-of-consensus was to have two or maybe three levels of
> param.*

On the #varnish channel today someone was wondering whether Varnish
cleared a panic report that never existed, because sigsegv_handler was
off. It is now on by default, which is good because it's one of the
must restart parameters.

If you're still looking for knobs to retire, this one is a good candidate. It
doesn't strike me as useful to omit panic reports.

Dridi

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