On Thu, Oct 2, 2008 at 4:54 AM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> Also, I agree that if speed were the *only* issue, we could start
> making a bunch of hacks to the existing protocol to get 'most' of the
> speedup we want -- make the client start constructing URIs by itself
> to eliminate turnarounds, stop using xml, etc. But a large goal here
> is to also make things more readable and maintainable for people who
> have never seen our HTTP layer before -- it should be as blindingly
> obvious as the svnserve protocol, not something steeped in DeltaV
> concepts.
My concern with using the svnserve protocol as a guide (as seems to be
the desire) is that it isn't easily broken down and multiplexed over
many connections. Our custom svnserve protocol is really intended to
be serviced over a single long-running persistent connection - with
most of the logic done server-side - my concern is that an ideal
HTTP-based protocol should do the exact opposite. Once we consider
latency (which we know is very critical for our use case), we probably
want to do as much computation on the client-side and not on the
server-side: keep the server as dumb (and efficient) as possible. I
believe that this has an impact on the best end protocol for our
uses...
HTTP servers are very good at parallelization. (If you look at Sun's
UltraSparc T1 aka Niagara2 CPUs, the individual CPUs are rather slow,
but there are lots of them. This is the direction a lot of web server
farms are moving to - lots of cheap but slower CPUs.) Also, with
things like repository mirroring being more available, I think
higher-end commodity sites - and not just Google Code Hosting - will
start to have load-balanced replicated read servers. svn.apache.org
already uses mirrors to give us geographic balancing. In a few years,
it should be more common to have a cluster of SVN servers per
geographic site. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-02 17:37:56 CEST