-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was curious, so I did some benchmarking of CLI performance. The good news is that we're doing a lot better in Trunk than in 1.16, and we have a clear win coming up.
For testing I just did: time for i in `seq 10`; do juju set-constraints mem=4G; done 143s juju-1.16 69s juju-trunk 23s juju-trunk w/ API caching For "API caching" I just filled in the user, password, state-servers, and ca-cert fields in the ~/.juju/environment/ENV.jenv. So the great news is that we're 2x faster than direct DB access today, and the even better news is that we can be 3x faster than we are *today* if we start caching the API parameters. These measurements were taken with an average 244ms ping time to the instance. Which means with API caching we're at about 10 round trips. SSL by itself takes 3-4 round trips. Wireshark says that there are about 43 frames involved. I managed to grab the server.pem and debug the traffic a bit. Unfortunately the Wireshark in Precise (1.6.7) doesn't support WebSocket traffic, but I was able to get an updated version. Anyway, the summary breakdown is: Time (ms) Action 0 TCP Connect 222 ACK, TLS Client Hello 444 Server Hello, Certificate, Server Done, Client Key Exchange, Change Cipher Spec *** 2 RTT here 959 Change Cipher Spec, Client GET / Upgrade: Websocket 1183 HTTP Switching Protocols, Login request *** 2 RTT 1530 Login Response {}, Request Pinger.Ping(), Request SetEnvironmentConstraints 1767 Pinger response 1991 SetEnvironmentConstraits Response, WebsocketClose() 2216 Websocket Connection Close Response, TCP Close So a couple of things to note: 1) We have 7 RTT before we have logged in. 1 TCP Connect, 3 TLS including a gap 1 Websocket upgrade request 2 Login including a gap I don't know why we have those 2 gaps. It doesn't seem like it should take an extra 200ms to setup TLS or Login. It is possible I have dropped packets or something, but I don't think I do. We also lose a round trip waiting for the Websocket response to come back. Is there any reason we can't just pipeline it and assume the Websocket request is going to succeed? Potentially we can shave 3 RTT here. If we can understand why there are 2 gaps, and we can pipeline the first Login request right after the "please upgrade to a Websocket". 2) Why are we calling Pinger.Ping() and why does that seem to trigger an extra round trip. We seem to call Ping and SetEnvironmentConstraints at the same time (1.530516 for Ping, and 1.530686 for SetEnvironmentConstraints), but the response for Ping comes a full RTT before the response for SetEnvironmentConstraints. I don't think we need the client to Ping. I think we were doing that as part of "give me an updated view of all the agents" but we don't actually care here. Alternatively, we *do* want to Ping for all connections to make sure they stay alive, but it doesn't seem like we need to *start* with a Ping, do we? (If it didn't delay the SetEnvironmentConstraints response, I wouldn't care) 3) Similarly to Login, can't we just pipeline our SetEnvironmentConstraints request? We don't actually seem to need to wait for Login to finish. There is no Response content, so there isn't anything like a Token that we need to do the next step. 4) We seem to be asking the Websocket to Close, and then wait for it to actually be closed. Why are we waiting? 5) So if we found a way to pipeline requests, and get rid of gaps, instead of taking 10 RTT, we could potentially get down to 5 RTT. (2 gaps, calling Upgrade + Login + SetEnvironmentConstraints immediately rather than waiting for responses, not waiting for Close). Is it worth pushing further on this? I certainly think the first thing to do is start caching the API, as we know we want to do that, but we potentially can speed it up *another* 2x by doing better pipelining. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Cygwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKQXcMACgkQJdeBCYSNAAM6zgCfY8go2flKOqpqTJ3fykYNqMuG 1I0An2ocoyHU8ypx4agptmZ3wTgGOuAx =eBw+ -----END PGP SIGNATURE----- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev