<div dir="ltr">Hi Dave,<div><br></div><div>I attached some status --debug logs to the bug for us-east-1 (30s instead of 35s in us-west-2).</div><div><br></div><div>cheers,</div><div><br></div><div>Kapil</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Sep 1, 2013 at 9:19 PM, David Cheney <span dir="ltr"><<a href="mailto:david.cheney@canonical.com" target="_blank">david.cheney@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
HI Kapil,<br>
<br>
I cannot reproduce your results, can you please post the output of<br>
juju status -v so we can see the timestamps.<br>
<br>
I 100% agree that is this a problem to be fixed, I am trying to<br>
determine if it is (yet another) ec2 region specific SNAFU.<br>
<br>
Cheers<br>
<br>
Dave<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Sep 2, 2013 at 11:12 AM, Kapil Thangavelu<br>
<<a href="mailto:kapil.thangavelu@canonical.com">kapil.thangavelu@canonical.com</a>> wrote:<br>
> Hi Folks,<br>
><br>
> Just to followup after some more investigation. For me on an ec2 environment<br>
> with 1-2 services, juju status was taking about 35s. I instrumented the code<br>
> base a little, and found that roughly 25s is endpoint lookup (both s3 and<br>
> ec2 api). That overhead was constant across any of the juju commands. So<br>
> number #3 would be the biggest win, i went ahead and filed issue 1219441 for<br>
> it. It seems like low hanging fruit that delivers a big win for the ux.<br>
><br>
> i went ahead and put together a juju cli plugin that does a status<br>
> approximation using endpoint caching and the api and was able to drop that<br>
> time down to 5s (from 35s on my env) and down to 2.5s on Peter's<br>
> environment. attached, inline docs and install instructions.<br>
><br>
> also regarding the dead machines stuck in pending state, there's a bug<br>
> outstanding for that <a href="https://bugs.launchpad.net/juju-core/+bug/1217781" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1217781</a><br>
><br>
> cheers,<br>
><br>
> Kapil<br>
><br>
><br>
><br>
><br>
> On Fri, Aug 30, 2013 at 2:15 PM, John Arbash Meinel <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>><br>
> wrote:<br>
>><br>
>> -----BEGIN PGP SIGNED MESSAGE-----<br>
>> Hash: SHA1<br>
>><br>
>> On 2013-08-30 14:28, Peter Waller wrote:<br>
>> > For the record, I sent the link privately. The run took about 22s<br>
>> > but I have measured 30s to 1m.<br>
>><br>
>> Some thoughts, nothing that I can give absolute confirmation on.<br>
>><br>
>> 1) Next week we have a group sprinting on moving a lot of the command<br>
>> line operations from being evaluated by the client into being<br>
>> evaluated by the API server (running in the cloud) and then returned.<br>
>> The explicit benefits that I've seen in other commands are pretty good.<br>
>><br>
>> 'juju status' is going to be a command that should see a rather large<br>
>> improvement. Because it does round trip queries for a lot of things<br>
>> (what machines are there, what are the details of each machine, what<br>
>> are the units running on each one, etc).<br>
>><br>
>> I've prototyped doing those queries in parallel, or trying to do bulk<br>
>> ops, which actually helped a lot in testing (this was for hundreds of<br>
>> units/machines).<br>
>><br>
>> Doing it on the API server means any round trips are "local" rather<br>
>> than from your machine out to Amazon.<br>
>><br>
>> 2) From here, 'time juju status' with a single instance running on ec2<br>
>> is 10s. Which breaks down roughly 4s to lookup the IP address, 2s to<br>
>> establish the state, and 4s to "finish up". (resolution of this is 1s<br>
>> granularity)<br>
>><br>
>> Similarly "time juju-1.13.2 get not-service" takes 8.5s to run. 4s to<br>
>> lookup the address, 2s to connect, and 3s to give the final 'not<br>
>> found' result.<br>
>><br>
>> With trunk, "time ./juju get not-service" is 4.6s. 2s to lookup IP<br>
>> address, 2s to connect, and the not-found result is instantaneous.<br>
>><br>
>> So I would expect the 10s of a generic "juju status" to easily drop<br>
>> down to sub 5s. Regardless of any round-trip issues.<br>
>><br>
>> 3) We are also looking to cache the IP address of the API server, to<br>
>> shave off another ~2-4s for the common case that the address hasn't<br>
>> changed. (We'll fall back to our current discovery mechanism.)<br>
>><br>
>> 4) There seems to be an odd timing of your screen cast. It does report<br>
>> 22s which matches the times reported in the debug output. But the<br>
>> total time of the video is 20s including typing. Is it just running<br>
>> 2:1 speed?<br>
>><br>
>> You can see from the debug that you have 7s to lookup the address to<br>
>> connect to, and then about 1s to connect. The rest is time spent<br>
>> gathering the information.<br>
>><br>
>> I expect it to get a whole lot faster in a couple more weeks, but I'm<br>
>> not going to guarantee that until we've finished the work.<br>
>><br>
>> 5) If I counted correctly, you have about 23 "machines" that are being<br>
>> considered. A bunch of them down/pending/errored.<br>
>><br>
>> I would think for the errored ones you could do some sort of "juju<br>
>> destroy-machine". It might make things better (less time spent<br>
>> checking on machines you don't care about.)<br>
>><br>
>> What happens when you try it? (There may be other issues that make us<br>
>> think we are waiting for something to happen with a machine that we<br>
>> don't want to destroy it.)<br>
>><br>
>><br>
>> Anyway in summary, this should be getting better, but I won't have<br>
>> explicit numbers until the work is done.<br>
>><br>
>> John<br>
>> =:-><br>
>> -----BEGIN PGP SIGNATURE-----<br>
>> Version: GnuPG v1.4.13 (Cygwin)<br>
>> Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
>><br>
>> iEYEARECAAYFAlIg4UIACgkQJdeBCYSNAAOfxQCeMaRQdqvdyQ11WyRnJ/WPAccp<br>
>> IysAniDrUq6IDtM0fu9SuZg+2AQto8rP<br>
>> =JaZw<br>
>> -----END PGP SIGNATURE-----<br>
>><br>
>> --<br>
>> Juju mailing list<br>
>> <a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
>> Modify settings or unsubscribe at:<br>
>> <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
><br>
><br>
><br>
> --<br>
> Juju mailing list<br>
> <a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
> Modify settings or unsubscribe at:<br>
> <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
><br>
</div></div></blockquote></div><br></div>