<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 20, 2016 at 10:28 AM, Dean Troyer <span dir="ltr"><<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Apr 20, 2016 at 9:43 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Cliff looks for commands on demand. If we modify it's command loader to<br>
support some "built in" commands, and then implement the commands in OSC<br>
that way, we can avoid scanning the real plugin system until we hit a<br>
command that isn't built in.<br></blockquote><div><br></div></span><div>Maybe down the road once this becomes a bigger percentage of the startup time, for now I do not (yet) believe the plugins are the problem others do.  See below...</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The last time I proposed that, though, someone (Dean?) pointed out that<br>
loading the plugins wasn't actually where OSC was spending its time. So,<br>
maybe we should profile the thing before proposing code changes.<br></blockquote><div><br></div></span><div>It has been a while since I looked into this in detail, we made a couple of changes then that helped, and since then the world kept moving and we're behind again. Right now OSC is a mess WRT keystoneclient/keystoneauth and their interactions with os-client-config.  We have lost sight of who is supposed to be doing what here.  I know for a fact that there is duplication in auth setup, we often make duplicate REST auth calls.</div><div><br></div><div>OSC 2.4.0 should be released today/tomorrow, following which we begin merging the cleanup starting with the ksc/ksa bits.</div><div><br></div><div>Here are a couple of things to consider for those who want to investigate further:</div><div>* OSC does not load _any_ project client (modulo the ksc bit mentioned above) unless/until it is actually needed to make a REST call.</div><div>* Timing on a help command includes a complete scan of all entry points to generate the list of commands</div><div>* The --timing option lists all REST calls that properly go through our TimingSession object.  That should be all of them unless a library doesn't use the session it is given (the ones used by the commands in the OSC repo all do this correctly).</div><div>* Interactive mode can be useful to get timing on just the setup/teardown process without actually running a command:</div><div><br></div><div>  time openstack </dev/null</div><div><br></div><div>So time for a couple of fun baselines, using the OSC SHA proposed for 2.4.0 (4639148b1d) on a Lenovo T420s with Ubuntu 14.0.4 against a DevStack on an Ubuntu 14.0.3 VM on a moderately-sized local NUC:</div><div><br></div><div><div>* time openstack --timing </dev/null</div><div>  * py2:<span style="white-space:pre-wrap"> </span>0m0.307s<br></div></div><div>  * py3: 0m0.376s</div><div><br></div><div>* time openstack --timing help</div><div>  * py2: 0m1.939s</div><div>  * py3: 0m1.803s</div><div><br></div><div>* time openstack --timing catalog list<br></div><div>  * py2: 0m0.675s - 0.360 REST = 0.315s</div><div>  * py3: 0m0.704s - 0.312 REST = 0.392s</div><div><br></div><div>* time openstack --timing flavor list</div><div>  * py2: 0m0.772s - 0.447 REST = 0.325s</div><div>  * py3: 0m2.563s - 2.146 REST = 0.417s</div><div><br></div><div>* time openstack --timing image list</div><div>  * py2: 0m0.860s - 0.517 REST = 0.343s</div><div>  * py3: 0m0.952s - 0.539 REST = 0.423s</div><div><br></div><div>Are there any conclusions to draw from this seat-of-the-pants look?</div><div><br></div><div>* The differences between py2 and py3 are small, and not consistent.</div><div>* The time for OSC to load and then exit immediately is within 0.1s of the time to execute a near-trivial command when the REST round trip times are removed.</div><div>* Two auth calls are consistently being made, this is one of the things actively being cleaned up with the ksc/ksa transition bits.  The additional REST round trip in these tests is consistently between 0.14s and 0.2s, so that gain will come soon.</div><div><br></div><div>I also have buried in my notes some out-of-date results of using boris-42's profimp that lead me to keystoneclient and the largest single static import being done and accounting for nearly half of the total static load time.  The transition to using ksa will help here, I do not have profimp numbers for that yet.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>dt</div><div><br></div></font></span></div></div></div></blockquote><div><br></div><div>This was one of the driving forces behind the move to KSA in general, eliminating and isolating the auth library to as small of a footprint as possible.</div><div><br></div><div>There is still some loading overhead due to the auth plugin system (hard to eliminate completely), but simple back-of-the-napkin numbers we did initially showed KeystoneAuth way ahead in the game (and much easier to improve upon since it is not tied to keystone CRUD interactions to get auth performance improvements released)</div></div><br></div></div>