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