You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2003/10/27 22:15:16 UTC
issue #1429 progress: ra_dav changing analogously to ra_svn
Here's an update re recent progress on the performance front:
Recently there was a lot of discussion about how the two network RA
layers were doing too many turnarounds during common operations (e.g.,
checkouts, updates). The number of turnarounds was proportional to
the number of items in the checkout -- badness.
Greg Hudson solved this for ra_svn, by implementing pipelining in
r7532. But for ra_dav, true pipelining is not yet feasible, unless we
want to rewrite Neon. So instead, Ben and I added a new attribute to
our report request, telling the server to send back file contents with
its custom update report (which is used for checkouts as well as
updates). Formerly, the server only sent a "skeleton delta" (skelta),
telling the client what files needed to be fetched from the server.
The client would then issue a standard httpd GET request for each file
in turn.
After our change, there are no more GET requests, hence, no more
turnarounds after the full [non-skelta] delta starts to arrive. The
delta contains all the necessary data, and the client can process it
streamily to create the appropriate working copy. (The patch is
attached to issue #1429, by the way.)
This change results in an appx 300% for remote checkout, over a link
with average 81 ms latency -- the Chicago office's T1 line to
CollabNet HQ in California. Here are some timed checkouts of the
Subversion r7428 tree, over CVS, stock Subversion, and Subversion with
the patch:
CVS SVN r7531 SVN r7531 + patch
---------- ---------- -----------------
1m21.733s 4m46.052s 1m1.295s
1m21.528s 4m21.998s 0m50.425s
1m24.678s 4m12.330s 0m55.898s
1m23.955s 3m52.263s 0m56.361s
1m25.752s 4m38.493s 0m51.013s
This is know as a "win" :-).
Some caveats:
1. Now we have an authorization problem. Because no GET requests
are being issued, mod_authz_svn doesn't work, becuase the
standard Apache authorization mechanism never kicks in. We will
find a way to solve this (probably some sort of generic authz
callback). Thoughts welcome.
2. The above patch only sends file contents right now, not props.
Things will slow down some when we add properties into the
delta, but we don't expect it to go back to 4 minutes, even with
translation. Especially not since r7502 (ghudson's translation
speedups).
3. On the other hand, even with the patch, the client is still
using the Neon compatibility shim code, which gathers all the
cdata in memory and then hands it to end_element() as a single
string. This is both a scalability problem, and waste of time,
and when we complete this patch we will undo the shim code and
use a real (streamy) cdata handler.
So that's the status. Watch issue #1429 for progress.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1429 progress: ra_dav changing analogously to ra_svn
Posted by kf...@collab.net.
Tobias Ringström <to...@ringstrom.mine.nu> writes:
> This change is great, because it completely removes the (unneccessary)
> latency performance problem. Unfortunately this does not tell us that
> SVN is faster than CVS, as one might think from the numbers abobe.
> The only reason SVN is faster here is because it compresses the data.
> If you enable comression for CVS, the time will be very close to SVN
> time.
Compressed CVS is actually faster (I didn't include those numbers, not
because I wanted to mislead anyone, but just because I didn't want to
add distractions to an already complex mail). With -z3, the same CVS
checkouts were averaging 33 seconds or so.
> If you increase the bandwidth, there comes a point where the checkout
> time does not go below a certain time becuse the server cannot
> generate data to transmit any faster, or because libsvn_wc cannot
> write the data any faster. The throughput at that point is the real
> performance limit, and I fear that CVS will still beat SVN by a wide
> margin there.
You are right. I already know this from doing the same tests over
ra_dav on localhost.
> Perhaps that sounded negative, but there is still reason to be glad,
> becuse from my own tests I can see that SVN can saturate a 2 Mbit link
> without even breaking a sweat. That means that it is fast enough for
> a lot of Internet applications, and at least to me, that is great news!
Yeah. It would be nice someday to beat CVS even in LAN performance --
but acceptable WAN performance is a first step, anyway! :-)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1429 progress: ra_dav changing analogously to ra_svn
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
kfogel@collab.net wrote:
> Here's an update re recent progress on the performance front:
Cool. Thanks for writing this.
> This change results in an appx 300% for remote checkout, over a link
> with average 81 ms latency -- the Chicago office's T1 line to
> CollabNet HQ in California. Here are some timed checkouts of the
> Subversion r7428 tree, over CVS, stock Subversion, and Subversion with
> the patch:
>
> CVS SVN r7531 SVN r7531 + patch
> ---------- ---------- -----------------
> 1m21.733s 4m46.052s 1m1.295s
> 1m21.528s 4m21.998s 0m50.425s
> 1m24.678s 4m12.330s 0m55.898s
> 1m23.955s 3m52.263s 0m56.361s
> 1m25.752s 4m38.493s 0m51.013s
>
> This is know as a "win" :-).
This change is great, because it completely removes the (unneccessary)
latency performance problem. Unfortunately this does not tell us that
SVN is faster than CVS, as one might think from the numbers abobe. The
only reason SVN is faster here is because it compresses the data. If
you enable comression for CVS, the time will be very close to SVN time.
But that does not tell us that they are about equally fast either. I
bet that for the CVS and SVN+patch tests above, you are using up all the
available bandwidth. That means that the performance of the SVN server
does not matter as long as it is fast enough to saturate the network.
If you increase the bandwidth, there comes a point where the checkout
time does not go below a certain time becuse the server cannot generate
data to transmit any faster, or because libsvn_wc cannot write the data
any faster. The throughput at that point is the real performance limit,
and I fear that CVS will still beat SVN by a wide margin there.
Perhaps that sounded negative, but there is still reason to be glad,
becuse from my own tests I can see that SVN can saturate a 2 Mbit link
without even breaking a sweat. That means that it is fast enough for a
lot of Internet applications, and at least to me, that is great news!
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1429 progress: ra_dav changing analogously to ra_svn
Posted by kf...@collab.net.
Brian Behlendorf <br...@collab.net> writes:
> > I'd just like to create an svn-aware SVN that has some intelligence in
> > it :-).
>
> You know, this self-deprecation routine was cute for the first 3 years,
> but now it's just tiresome. :)
>
> (ok, I hate overusing smileys too, but I just want to make it clear I'm
> intending the above as IRONY, as I'm sure Karl was.)
*Someone* obviously didn't spend the day wrestling with a tradeoff
between authorization and performance...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1429 progress: ra_dav changing analogously to ra_svn
Posted by Brian Behlendorf <br...@collab.net>.
On Mon, 27 Oct 2003 kfogel@collab.net wrote:
> Brian Behlendorf <br...@collab.net> writes:
> > Agreed. Just looking ahead to when this stuff would be useful &
> > important. If it is, we could create a svn-aware proxy that had some
> > extra intelligence in it.
>
> Whew!
>
> I'd just like to create an svn-aware SVN that has some intelligence in
> it :-).
You know, this self-deprecation routine was cute for the first 3 years,
but now it's just tiresome. :)
(ok, I hate overusing smileys too, but I just want to make it clear I'm
intending the above as IRONY, as I'm sure Karl was.)
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1429 progress: ra_dav changing analogously to ra_svn
Posted by kf...@collab.net.
Brian Behlendorf <br...@collab.net> writes:
> Agreed. Just looking ahead to when this stuff would be useful &
> important. If it is, we could create a svn-aware proxy that had some
> extra intelligence in it.
Whew!
I'd just like to create an svn-aware SVN that has some intelligence in it :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1429 progress: ra_dav changing analogously to ra_svn
Posted by Brian Behlendorf <br...@collab.net>.
On Mon, 27 Oct 2003 kfogel@collab.net wrote:
> Yep, your understanding is correct (sharp eyes!). But as Greg Hudson
> pointed out, we know of no instances of people taking advantage of
> proxy caching for Subversion, and it makes no sense to penalize all
> users for the sake of no users.
>
> Perhaps it should be listed as another caveat, but I think it's not a
> very major one. CVS users have never had any caching at all.
Agreed. Just looking ahead to when this stuff would be useful &
important. If it is, we could create a svn-aware proxy that had some
extra intelligence in it.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1429 progress: ra_dav changing analogously to ra_svn
Posted by kf...@collab.net.
Brian Behlendorf <br...@collab.net> writes:
> This is a great optimization. But, I can think of one more caveat: it
> keeps us from being able to take advantage of HTTP proxy servers, if I
> understand it correctly, unless two people happen to be updating from the
> same old rev # to the same new rev #. Perhaps the old method wasn't
> really HTTP proxy-friendly anyways, I've not thought about this area for
> awhile.
Yep, your understanding is correct (sharp eyes!). But as Greg Hudson
pointed out, we know of no instances of people taking advantage of
proxy caching for Subversion, and it makes no sense to penalize all
users for the sake of no users.
Perhaps it should be listed as another caveat, but I think it's not a
very major one. CVS users have never had any caching at all.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1429 progress: ra_dav changing analogously to ra_svn
Posted by Brian Behlendorf <br...@collab.net>.
This is a great optimization. But, I can think of one more caveat: it
keeps us from being able to take advantage of HTTP proxy servers, if I
understand it correctly, unless two people happen to be updating from the
same old rev # to the same new rev #. Perhaps the old method wasn't
really HTTP proxy-friendly anyways, I've not thought about this area for
awhile.
Brian
On Mon, 27 Oct 2003 kfogel@collab.net wrote:
> Some caveats:
>
> 1. Now we have an authorization problem. Because no GET requests
> are being issued, mod_authz_svn doesn't work, becuase the
> standard Apache authorization mechanism never kicks in. We will
> find a way to solve this (probably some sort of generic authz
> callback). Thoughts welcome.
>
> 2. The above patch only sends file contents right now, not props.
> Things will slow down some when we add properties into the
> delta, but we don't expect it to go back to 4 minutes, even with
> translation. Especially not since r7502 (ghudson's translation
> speedups).
>
> 3. On the other hand, even with the patch, the client is still
> using the Neon compatibility shim code, which gathers all the
> cdata in memory and then hands it to end_element() as a single
> string. This is both a scalability problem, and waste of time,
> and when we complete this patch we will undo the shim code and
> use a real (streamy) cdata handler.
>
> So that's the status. Watch issue #1429 for progress.
>
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org