Open Stack

On 12 August 2014 08:35, Zane Bitter <zbitter at redhat.com> wrote:

> This sounds like the same figure I heard at the design summit; did the DB
> call optimisation work that Steve Baker did immediately after that not have
> any effect?

It helped a lot- I'm not sure where heat tops out now - I'm not aware
of rigorous benchmarks at this stage - I'm hoping we can get a large
scale integration test (virtual machine based) up soon periodically.
Ideally we'd have a microtest in the gate.


>> That was the issue. So we fixed that bug, but we never un-reverted
>> the patch that forks enough engines to use up all the CPU's on a box
>> by default. That would likely help a lot with metadata access speed
>> (we could manually do it in TripleO but we tend to push defaults. :)
>
>
> Right, and we decided we wouldn't because it's wrong to do that to people by
> default. In some cases the optimal running configuration for TripleO will
> differ from the friendliest out-of-the-box configuration for Heat users in
> general, and in those cases - of which this is one - TripleO will need to
> specify the configuration.

So - thanks for being clear about this (is it in the deployer docs for heat?).

That said, nova, neutron and other projects are defaulting to
one-worker-per-core, so I'm surprised that heat considers this
inappropriate, but our other APIs consider it appropriate :) Whats
different about heat that makes this a bad default?

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud