Justin Erenkrantz wrote:
> On Tue, Sep 30, 2008 at 2:22 PM, Ben Collins-Sussman
> <sussman_at_red-bean.com> wrote:
>> Would turn into a request like this:
>>
>> GET /repos?cmd=rev-proplist&r=23
>
> I'm repeating a bit what Greg already commented in the docs, but yuck.
> This is a *very* ugly way to do this. Plus, you are killing off any
> way of doing caching by using query args. Any solution that we do
> should be very simple and scale with good HTTP proxy caches, IMO.
>
> A lot of the extra round-trips with DeltaV come from property-hell -
> splitting things up into multiple requests is a *good* thing - big,
> giant API calls are a disaster and should be avoided. Thinking that
> more 'REPORT' calls is the answer seems like we're going down the
> wrong path. Fine-grained and quick APIs should be our desire, IMO.
Are you talking about the ra API here? Or about the mod_dav_svn API?
If you want to do decent pipelining you need to make less calls to the
ra API, so that each call can pipeline multiple requests to the server.
Take the example of svnsync. In 1.5, svnsync over ra_serf is three times
as fast as over ra_neon. How? By pipelining the PROPFIND and GET
requests over the same connection. Now in order to be able to do that,
we needed to replace the 'replay' API with 'replay_range', so now
there's only one ra call for all the revisions to sync, instead of rev.
per rev. Obviously replay is very specific and well-suited for this type
of pipelining.
I'm just saying, in order to maximize performance over serf we'll need
to review the ra API too.
..
>
> The one killer feature I want to add to ra_serf is commit
> parallelization - this is something that svnserve can't do (it does
> just a tiny bit of commit pipelining), but I think we can come up with
> a clever way of doing it. And, honestly, DeltaV isn't *too* bad when
> it comes to this, so it's probably already somewhat doable, but
> there's some nasty request dependency issues.
>
That's one thing. But the performance bottlenecks are not always inside
the ra layer. If you look at merge tracking right now, for a reasonable
sized merge, you're looking at the ra layer opening 100's of connections
to the server. Now that's slow on its own, but if you add a Kerberos and
SSL handshake to the connection startup time you get dog slow
performance. Fixing this issue alone will have more impact on
performance than replacing XML with protobuffers.
Lieven
---------------------------------------------------------------------
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 12:46:14 CEST