-----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
