Open Stack

On 02/14/2019 09:47 AM, Chris Dent wrote:
>>> * Because of a combination of "we might need it later", "it's a
>>>    handy tool and constraint" and "that's the way we do things" the
>>>    interface between the placement URL handlers and the database is
>>>    mediated through oslo versioned objects. Since there's no RPC, nor
>>>    inter-version interaction, this is overkill. It also turns out that
>>>    OVO getters and setters are a moderate factor in performance.
>>
>> Data please.
> 
> When I wrote that bullet I just had some random profiling data from
> running a profiler during a bunch of requests, which made it clear
> that some ovo methods (in the getters and setters) were being called
> a ton (in large part because of the number of objects invovled in an
> allocation candidates response). I didn't copy that down anywhere at
> the time because I planned to do it more formally.
> 
> Since then, I've made this:
> 
> https://review.openstack.org/#/c/636631/
> 
> That's a stack which removes OVO from placement. While we know the
> perfload job is not scientific, it does provide a nice quide. An
> ovo-using patch
> <http://logs.openstack.org/95/633595/2/check/placement-perfload/267131a/logs/placement-perf.txt.gz> 
> 
> has perfload times of 2.65-ish (seconds).
> 
> The base of that OVO removal stack (which changes allocation
> candidates) <
> http://logs.openstack.org/31/636631/4/check/placement-perfload/a413724/logs/placement-perf.txt> 
> 
> is 2.3-ish.
> 
> The end of it
> <http://logs.openstack.org/07/636807/2/check/placement-perfload/fa7d58f/logs/placement-perf.txt> 
> 
> is 1.5-ish.
> 
> And there are ways in which the code is much more explicit. There's
> plenty of cleanup to do, and I'm not wed to us making that change if
> people aren't keen, but I can see a fair number reasons above and
> beyond peformance to do it but that might be enough. Lot's more info
> in the commits and comments in that stack.

bueno. :) I'll review that series over the next couple days.

Great work, Chris.

-jay