[openstack-dev] [devstack] openstack client slowness / client-as-a-service

Morgan Fainberg morgan.fainberg at gmail.com
Tue Apr 19 15:15:08 UTC 2016


On Tue, Apr 19, 2016 at 7:57 AM, Dean Troyer <dtroyer at gmail.com> wrote:

> On Tue, Apr 19, 2016 at 9:06 AM, Adam Young <ayoung at redhat.com> wrote:
>
>> I wonder how much of that is Token caching.  In a typical CLI use patter,
>> a new token is created each time a client is called, with no passing of a
>> token between services.  Using a session can greatly decrease the number of
>> round trips to Keystone.
>>
>
> Not as much as you think (or hope?).  Persistent token caching to disk
> will help some, at other expenses though.  Using --timing on OSC will show
> how much time the Identity auth round trip cost.
>
> I don't have current numbers, the last time I instrumented OSC there were
> significant load times for some modules, so we went a good distance to
> lazy-load as much as possible.
>
> What Dan sees WRT a persistent client process, though, is a combination of
> those two things: saving the Python loading and the Keystone round trips.
>
> I have (had!) a version of DevStack that put OSC into a subprocess and
> called it via pipes to do essentially what Dan suggests.  It saves some
> time, at the expense of complexity that may or may not be worth the effort.
>
> One thing missing is any sort of transactional control in the I/O with the
> subprocess, ie, an EOT marker.  I planned to add a -0 option (think xargs)
> to handle that but it's still down a few slots on my priority list.  Error
> handling is another problem, and at this point (for DevStack purposes
> anyway) I stopped the investigation, concluding that reliability trumped a
> few seconds saved here.
>
> Ultimately, this is one of the two giant nails in the coffin of continuing
> to persue CLIs in Python.  The other is co-installability. (See that
> current thread on the ML for pain points).  Both are easily solved with
> native-code-generating languages.  Go and Rust are at the top of my
> personal list here...
>
> dt
>

+1 for Rust (though I'd totally support Go as well) as personal choices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160419/92764272/attachment.html>


More information about the OpenStack-dev mailing list