[merge] Implement put_bytes_non_atomic for smart server

[Robert Collins]

On Sat, 2006-09-16 at 01:49 -0500, John Arbash Meinel wrote:
> The attached patch adds 'put_bytes_non_atomic' for the smart server.
> This allows us to avoid a bunch of round trips when creating new
> directories on the remote end. This is only really a win for pushing a
> new project, since once a project is established we rarely get many
> remote directories that need to be updated.
> 
> For a small branch (a plugin of mine with 29 revisions), over sftp and
> the same 35ms latency, 30KB/s up, 160KB/s down:
> 
> sftp		21-30s
> bzr.dev		10-14s
> put-nonatomic	9-13s
> 
> This isn't as big of a win as the readv() changes. It only saves a few
> round trips (at most 256*2, one for the failed put, and one for the
> mkdir for each new directory)
> 
> Now, this will have bigger benefits for projects with larger changes,
> since the SmartServer's put() command involves sending all of the data.
> 
> So if we fail to create a .knit file, we have to send all of that data a
> second time.
> 
> The times for pushing all of bzr.dev look like this:
> 
> sftp		21:12.59
> bzr.dev		21:11.32
> put-nonatomic	20:21.43
> bzr-0.10 sftp	25:15.25
> 
> These take long enough, that I only ran each one a single time. One good
> thing is to see that the put_non_atomic code and other knit fixes really
> will make bzr-0.11 quite a bit faster than 0.10 over any protocol.
> 
> By the way, there seems to be a bug in the protocol when there is a ','
> in the path. I originally tried to push to 'bzr://host:port/,tmp' and it
> kept telling me:
> 
>  Path
> 'bzr://phoenician.i-clic.uihc.uiowa.edu:9999/,tmp/test-version-info/' is
> not a child of path 'bzr://phoenician.i-clic.uihc.uiowa.edu:9999/%2Ctmp/'
> 
> So something is using an unescaped url, and something else is using the
> escaped form, and .relpath() is being called.
> 
> So this isn't as big a win, but I still think it is useful.
> 
> Oh, and it is important to note that pushing a bzr.dev tree moves about
> 40MB of data, and 40MB / 20min ~= 33KB/s. So it seems to be completely
> maxing out my upload capacity, which is a good sign.

This suffers the same model issues as the readv patch, though less
obviously (and less instrusively). I think it still should get a test
for the encoding and decoding of the protocol and a fixme for the
presence of decoding logic in the SmartServer.

I'm merging that into my smart-transport branch now, to do that. 

Cheers,
Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060918/878363de/attachment.pgp