Re: Default performance of ‘lp:foo’ URLs

[Martin Pool]

2009/12/2 Andrew Cowie <andrew at operationaldynamics.com>:
> On Tue, 2009-12-01 at 22:44 +1100, Robert Collins wrote:
>> On Tue, 2009-12-01 at 17:36 +0900, Stephen J. Turnbull wrote:
>> > Robert Collins writes:
>> >
>> >  > Its not implausible that bzr+http would be faster than bzr+ssh.
>> >
>> > It doesn't seem likely that the difference would be enough that people
>> > would really care, though.  Once you've got a smart server running,
>> > the only time transport time should matter is on a clone, right?
>>
>> Setting up ssh from here is ~ as long as an incremental push :)
>
> Isn't the real question here pull (ie, initial checkout, or large
> catchup?) times ie trying to choose between recommending people use
>
>        1a. $ bzr pull http://...
>        1b. $ bzr pull bzr+http://...
>
>        2   $ bzr pull bzr://...
>
>        3   $ bzr pull bzr+ssh://...
>
> to get or s/pull/branch/ your code?
>
> [ie, aren't bzr+ssh:// and sftp:// the only ways to push remotely, so
> for pushing bzr+ssh is a given in most cases?]

I don't know what this thread is about anymore.  Originally, it was
about the fact that Launchpad should offer anonymous users an option
other than 1a.  I think it's a great suggestion and I hope somebody
steps up to do it.  1b, 2, and 3 have slightly different
ease-of-implementation, robustness and performance characteristics,
but all of them are improvements and none is drastically superior to
the others.  Therefore it is unsurprising that different people
measuring them get different results.

For people other than Launchpad I would recommend they use whatever
they think will be easiest to deploy securely.

> Is `missing` a good way to test these things? In my present experience,
> bzr missing bzr:// is 2.3s whereas bzr missing http:// is 3.7s, from
> which I infer that recommending people use the Bazaar smart server
> protocol over 4331is a good idea (if it's technically and policy
> feasible for them to deploy, of course).

Missing is a pretty good test because it does some nontrivial graph traversal.

If you want to dig deeper run with -Dhpps and -Dhttp which will log
the requests done.  I expect the 3.7:2.3 time ratio will roughly
correspond to the number of queries, if latency dominates.

-- 
Martin <http://launchpad.net/~mbp/>