On 12 August 2014 08:35, Zane Bitter <zbit...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev