bzr to launchpad is slower than to devpad
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
High
|
Unassigned | ||
Launchpad itself |
Triaged
|
High
|
Unassigned |
Bug Description
On Mon, 2010-11-15 at 11:27 -0600, Edwin Grubbs wrote:
> -------
> DVCS | Destination server | Elapsed time (sec)
> -------
> BZR | bazaar.
> BZR | devpad.
> BZR | slicehost vm in Dallas datacenter | 2.10
> GIT | github in Virginia datacenter | 1.85
Those numbers were measured from Texas so it's not surprising that connecting to London is slower than both US destinations. But it is surprising and bad that connecting to Launchpad is so much worse than connecting to a machine in the same datacentre.
This is for pushing a new stacked branch; pushing into an existing stacked branch is reported to have similar issues.
We should reproduce this, and break it down into more detailed bugs. It may require multiple fixes on either the lp or bzr side. Please use this bug for overall analysis of the problem.
description: | updated |
Changed in bzr: | |
status: | New → Confirmed |
importance: | Undecided → High |
milestone: | none → 2.3b4 |
Changed in launchpad-code: | |
status: | New → Triaged |
importance: | Undecided → Medium |
tags: | added: codehosting-ssh |
Changed in bzr: | |
milestone: | 2.3b4 → 2.3.0 |
Changed in launchpad: | |
importance: | Medium → High |
tags: | added: check-for-breezy |
tags: | removed: check-for-breezy |
I'm timing to Chinstrap rather than Devpad because I can't get Paramiko to do the chinstrap song-and-dance to create an nc tunnel. However, the data center stuff should be the same.
$ time bzr log bzr+ssh://<email address hidden> /~bzr-pqm/ bzr/bzr. dev -r -1 edium(bzr+ ssh://< email address hidden>/)
...
HPSS calls: 16 (9 vfs) SmartSSHClientM
real 0m9.203s
$ time bzr log bzr+ssh://<email address hidden> /home/jameinel/ dev/bzr/ bzr.dev -r -1 edium(bzr+ ssh://< email address hidden>/)
...
HPSS calls: 19 (9 vfs) SmartSSHClientM
real 0m9.471s
So at least that part is quite comparable from Chicago. Though chinstrap probably has more pack files.
'info' is also pretty comparable: /~bzr-pqm/ bzr/bzr. dev edium(bzr+ ssh://< email address hidden>/)
$ time bzr info bzr+ssh://<email address hidden>
HPSS calls: 12 (0 vfs) SmartSSHClientM
real 0m7.704s
$ time bzr info bzr+ssh://<email address hidden> /home/jameinel/ dev/bzr/ bzr.dev edium(bzr+ ssh://< email address hidden>/)
HPSS calls: 15 (0 vfs) SmartSSHClientM
real 0m6.081s
A bit slower, but nothing like the 13s vs 5.8s we see in the initial report.
My initial guess is that stacked branches may have a specific impact here, and it may depend on the specific pack layout. Pushing up a stacked branch does at least some amount of data correctness check, which can be impacted by repo layout. So if devpad was more packed than Launchpad, that might impact this timing.
I think relevant to the discussion would be the time to push a new branch into a shared repository, since I think that is what the git code is doing.