On Thu, Oct 2, 2008 at 10:37 AM, Justin Erenkrantz
<justin_at_erenkrantz.com> wrote:
> 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
>
Fair enough. Let me start with a naive design of "one request per RA
API", and then we can start going over the requests one-by-one and
push them towards more pipelining and client-side-smarts. I agree
with these goals. Let me get all the RA APIs into the designdoc
first.
---------------------------------------------------------------------
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 18:36:22 CEST