Smart server usage

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eugene Wee wrote:
> The smart server documentation currently linked from the home page of
> the Bazaar website lists three ways to run the smart server:
> 
> a) Install Bazaar on the server, then use the bzr+ssh scheme.
> 
> b) Install Bazaar on the server, provide an appropriate inetd.conf
> entry, then use the bzr scheme.
> 
> c) Install Bazaar on the server, run bzr serve as a user, then use the
> bzr scheme. 4155 is the IANA assigned port number.
> 
> I am also aware that bzr+http was made available earlier this year (bzr
> 0.14). Is it like bzr+ssh in that it does not require any configuration
> to the server other than installing Bazaar, though it can be used with
> the dedicated server and thus have write access enabled?

It is discussed in doc/http_smart_server.txt, there is also an html version
available from:

http://doc.bazaar-vcs.org/bzr.dev/http_smart_server.htm

Can you tell me what page you were linked to, so that we can update it to
include a reference to the HTTP smart server setup?

> 
> What kind of performance gain can be expected from the smart server at
> this point? Like, how would using say, the bzr+ssh scheme compare with
> just using sftp, and bzr+http with http? Is there a penalty to not
> running the smart server in dedicated mode?
> 
> Thanks,
> Eugene Wee
> 
> 

I'll try to hit the quick points for bzr <= 0.18

a) bzr+ssh is usually much faster than sftp://. Mostly noticeable for a large
'push' or 'pull'. Because for sftp:// you have to open(), read(), close(),
which is 3 round trips to get data from 1 file. Even without advanced changes,
bzr+ssh is a single read(path, bytes) call.

For very quick functions (bzr update when nothing has changed) it can be
slightly slower. Because we have to spawn 'bzr' on the remote side, while
'sftp' is already running. Dedicated 'bzr://' and 'bzr+http://' would both
already have a service running, so wouldn't encounter this. (Note, we are
talking about <500ms here, but when the command only takes 250ms, it is noticeable)

b) We have code in place so that the first "branch" of a project into a new
repository can copy the whole thing as a large tarball. This makes 'initial
branch' significantly faster. There are some constraints on when it can be
used, though, so it is mostly a hack that we will be fixing up.

c) Andrew Bennetts is currently working on a very nice streaming api for the SS
so that we can stream any set of revisions. I'm crossing my fingers that we can
whip him into getting it into 0.19. This would end up being a benefit across
*all* bzr+ssh://, bzr://, bzr+http://

d) bzr:// and bzr+http:// can indeed be set up to allow writes. The default
configuration for both is to be readonly, because bzr:// doesn't have
authentication, and bzr+http:// would often not as well.
The http_smart_server.txt doc does describe how to set up a writable https://
connection. (Though it could probably use a bit more clarity).
In general, bzr doesn't do auth, because we expect you to set that up through
ssh/http/etc. We don't really want to create our own auth scheme, and have to
worry about all the security, etc, details.

e) As far as "streaming" versus "file-by-file". Until (c) is in place, we
generally go file-by-file anyway. However, once we have (c) we will stream
across all protocols. The "smart server" layer is intended to be as stateless
as HTTP, so we can communicate using smarter requests without having to
maintain a connection.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGrfqVJdeBCYSNAAMRAqMiAKCJVzUPgSL3ULnnUEaESalMYl2qygCfaTSb
KuXJ/NbAPZngMaejlpfbFj4=
=KWDB
-----END PGP SIGNATURE-----