juju is slow to do anything

[Gustavo Niemeyer]

I was planning to mumble something about how the API would improve
performance, but that message is great John. Full of insightful
details.

Thanks!

On Fri, Aug 30, 2013 at 3:15 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2013-08-30 14:28, Peter Waller wrote:
>> For the record, I sent the link privately. The run took about 22s
>> but I have measured 30s to 1m.
>
> Some thoughts, nothing that I can give absolute confirmation on.
>
> 1) Next week we have a group sprinting on moving a lot of the command
> line operations from being evaluated by the client into being
> evaluated by the API server (running in the cloud) and then returned.
> The explicit benefits that I've seen in other commands are pretty good.
>
> 'juju status' is going to be a command that should see a rather large
> improvement. Because it does round trip queries for a lot of things
> (what machines are there, what are the details of each machine, what
> are the units running on each one, etc).
>
> I've prototyped doing those queries in parallel, or trying to do bulk
> ops, which actually helped a lot in testing (this was for hundreds of
> units/machines).
>
> Doing it on the API server means any round trips are "local" rather
> than from your machine out to Amazon.
>
> 2) From here, 'time juju status' with a single instance running on ec2
> is 10s. Which breaks down roughly 4s to lookup the IP address, 2s to
> establish the state, and 4s to "finish up". (resolution of this is 1s
> granularity)
>
> Similarly "time juju-1.13.2 get not-service" takes 8.5s to run. 4s to
> lookup the address, 2s to connect, and 3s to give the final 'not
> found' result.
>
> With trunk, "time ./juju get not-service" is 4.6s. 2s to lookup IP
> address, 2s to connect, and the not-found result is instantaneous.
>
> So I would expect the 10s of a generic "juju status" to easily drop
> down to sub 5s. Regardless of any round-trip issues.
>
> 3) We are also looking to cache the IP address of the API server, to
> shave off another ~2-4s for the common case that the address hasn't
> changed. (We'll fall back to our current discovery mechanism.)
>
> 4) There seems to be an odd timing of your screen cast. It does report
> 22s which matches the times reported in the debug output. But the
> total time of the video is 20s including typing. Is it just running
> 2:1 speed?
>
> You can see from the debug that you have 7s to lookup the address to
> connect to, and then about 1s to connect. The rest is time spent
> gathering the information.
>
> I expect it to get a whole lot faster in a couple more weeks, but I'm
> not going to guarantee that until we've finished the work.
>
> 5) If I counted correctly, you have about 23 "machines" that are being
> considered. A bunch of them down/pending/errored.
>
> I would think for the errored ones you could do some sort of "juju
> destroy-machine". It might make things better (less time spent
> checking on machines you don't care about.)
>
> What happens when you try it? (There may be other issues that make us
> think we are waiting for something to happen with a machine that we
> don't want to destroy it.)
>
>
> Anyway in summary, this should be getting better, but I won't have
> explicit numbers until the work is done.
>
> John
> =:->
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (Cygwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlIg4UIACgkQJdeBCYSNAAOfxQCeMaRQdqvdyQ11WyRnJ/WPAccp
> IysAniDrUq6IDtM0fu9SuZg+2AQto8rP
> =JaZw
> -----END PGP SIGNATURE-----
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju



-- 

gustavo @ http://niemeyer.net