Comment 9 for bug 680763

Good idea. Staging is offline still, but qastaging works:

mbp@joy% time bzr -Dhpss -Dhpssdetails push lp://qastaging/~mbp/+junk/docdiff-test2
Created new branch.
HPSS calls: 14 (1 vfs) SmartSSHClientMedium(bzr+ssh://<email address hidden>/)
bzr -Dhpss -Dhpssdetails push lp://qastaging/~mbp/+junk/docdiff-test2 0.28s user 0.05s system 1% cpu 17.856 total

mbp@joy% time bzr -Dhpss -Dhpssdetails push lp://qastaging/~mbp/+junk/docdiff-test3
Created new branch.
HPSS calls: 14 (1 vfs) SmartSSHClientMedium(bzr+ssh://<email address hidden>/)
bzr -Dhpss -Dhpssdetails push lp://qastaging/~mbp/+junk/docdiff-test3 0.27s user 0.06s system 2% cpu 16.103 total

So that's 2.8-4.5s slower than chinstrap, and 1.8-3.5s faster than lpnet. The time from starting to open the ssh connection until it gets the response is 5.69s, which is basically the same as chinstrap, and indicates that John's fix for bug 660264 should basically bring lp to parity with another machine in the dc as far as opening an ssh connection and starting bzr.

initialize_ex_1.16 took 1.4s on the second run and 1.7s on the first run, which is pretty interesting: right between the time for bzr running alone and bzr running on lpnet. It may be the qastaging database or internal xmlrpc is less loaded, but on the other hand it's a smaller database.

I guess we could write a script that just does this call repeatedly.