Open Stack

Excerpts from Anant Patil's message of 2015-08-30 23:01:29 -0700:
> Hi Angus,
> 
> Thanks for doing the tests with convergence. We are now assured that
> convergence has not impacted the performance in a negative way. Given
> that, in convergence, a stack provisioning process goes through a lot of
> RPC calls, it puts a lot of load on the message broker and the request
> looses time in network traversal etc., and in effect would hamper the
> performance. As the results show, having more than 2 engines will always
> yield better results with convergence. Since the deployments usually
> have 2 or more engines, this works in favor of convergence.
> 
> I have always held that convergence is more for scale (how much/many)
> than for performance (response time), due to it's design of distributing
> load (resource provisioning from single stack) among heat engines and
> also due to the fact that heat actually spends a lot of time waiting for
> the delegated resource request to be completed, not doing much
> computation. However, with these tests, we can eliminate any
> apprehension of performance issues which would have inadvertently
> sneaked in, with our focus more on scalability and reliability, than on
> performance.
> 
> I was thinking we should be doing some scale testing where we have many
> bigger stacks provisioned and compare the results with legacy, where we
> measure memory, CPU and network bandwidth.
> 

Convergence would be worth it if it was 2x slower in response time, and
scaled 10% worse. Because while scalability is super important, the main
point is resilience to failure of an engine. Add in engine restarts,
failures, etc, to these tests, and I think the advantages will be quite
a bit more skewed toward convergence.

Really nice work everyone!