Open Stack

On Wed, Apr 20, 2016 at 10:28 AM, Dean Troyer <dtroyer at gmail.com> wrote:

> On Wed, Apr 20, 2016 at 9:43 AM, Doug Hellmann <doug at doughellmann.com>
> wrote:
>
>> Cliff looks for commands on demand. If we modify it's command loader to
>> support some "built in" commands, and then implement the commands in OSC
>> that way, we can avoid scanning the real plugin system until we hit a
>> command that isn't built in.
>>
>
> 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...
>
>
>> The last time I proposed that, though, someone (Dean?) pointed out that
>> loading the plugins wasn't actually where OSC was spending its time. So,
>> maybe we should profile the thing before proposing code changes.
>>
>
> 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.
>
> OSC 2.4.0 should be released today/tomorrow, following which we begin
> merging the cleanup starting with the ksc/ksa bits.
>
> Here are a couple of things to consider for those who want to investigate
> further:
> * OSC does not load _any_ project client (modulo the ksc bit mentioned
> above) unless/until it is actually needed to make a REST call.
> * Timing on a help command includes a complete scan of all entry points to
> generate the list of commands
> * 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).
> * Interactive mode can be useful to get timing on just the setup/teardown
> process without actually running a command:
>
>   time openstack </dev/null
>
> 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:
>
> * time openstack --timing </dev/null
>   * py2: 0m0.307s
>   * py3: 0m0.376s
>
> * time openstack --timing help
>   * py2: 0m1.939s
>   * py3: 0m1.803s
>
> * time openstack --timing catalog list
>   * py2: 0m0.675s - 0.360 REST = 0.315s
>   * py3: 0m0.704s - 0.312 REST = 0.392s
>
> * time openstack --timing flavor list
>   * py2: 0m0.772s - 0.447 REST = 0.325s
>   * py3: 0m2.563s - 2.146 REST = 0.417s
>
> * time openstack --timing image list
>   * py2: 0m0.860s - 0.517 REST = 0.343s
>   * py3: 0m0.952s - 0.539 REST = 0.423s
>
> Are there any conclusions to draw from this seat-of-the-pants look?
>
> * The differences between py2 and py3 are small, and not consistent.
> * 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.
> * 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.
>
> 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.
>
> dt
>
>
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.

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160420/ab87e765/attachment.html>