On 2014-22-04 22:39, Felix Frank wrote:
On 04/21/2014 11:29 PM, Henrik Lindberg wrote:
* Any use cases you feel strongly about? Scenarios we need to consider...
Following the ongoing discussion, I start to feel that we are really
setting ourselves up for quite some additional pleas for help on the
mailing lists. Whenever people whitness weird behavior that may be
related to caching effects (oh good old days of 0.25 masters sans
modules) we'll be asking back for their precise caching settings. If
those differ from our own, we will always nourish the slight doubt that
there may be latent bugs in whatever strategy the user is employing etc.
What I'm getting at is - do we want this kind of flexibility out there?
Or would we rather now agree about the strategy that is least awful for
the majority of use cases?
Thanks,
Felix
There are basically three settings that make sense for different use cases.
REBOOT - actually setting timeout to "unlimited" or a very long time.
You can force it to reload by using the graceful restart, or simply by
rebooting.
TIMEOUT - a compromise, when willing to sacrifice some cycles now and
again (every n minutes) in order to not having to do a manual graceful
shutdown.
NEVER - actually setting timeout to "0" will not cache at all. This is
good for development.
Since these cache evictions are based on time to live, and it does not
really destroy anything (it just stops holding on to it). It will only
evict the cache entry on a request to get a particular environment. It
then holds on to this current environment throughout the compilation.
The directory environment does not memoize the environments so it should
be safe to just not remember it.
The PR we are working on (and will announce shortly) also drops the
scanning behavior when an Environment is an "directory based environment".
The main problem with directory based slow down observed seems to be
caused by a bug that in the worst case could load an environment for
every resource. We noticed > 20x performance degradation in this
scenario (with the given set of manifests to load - someone else with
even more resources could see even worse numbers - or so we think).
The benchmark numbers we have now looks promising.
(Back soon with a post about the PR, and how to try it out)
Regards
- henrik
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/lj73n8%2477f%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
