On 12/24/06, John Szakmeister <john@szakmeister.net> wrote:
> > Lemme know how it fares for you. =)
>
> Any updates on ra_serf's performance as compared to ra_dav? Performance would be the primary motivation behind making it the default, right?
For me, it's about the same (margin of error) with lower user-time CPU
usage on average. At the summit, I think Ben said that it seemed
faster than ra_dav on his MBP. Ivan's said that it's much faster on
Windows than ra_dav. I'll admit that it depends on a lot of factors:
prevailing network conditions, etc. I'd expect for high-latency
connections, doing multiplexed pipelined connections could likely be a
win.
Here's one unscientific datapoint I can tell you right now:
[ra_serf] svn co http://svn.collab.net/repos/svn/trunk 3.06s user
7.29s system 63% cpu 16.356 total
[ra_dav] svn co http://svn.collab.net/repos/svn/trunk 4.20s user
4.42s system 54% cpu 15.863 total
As we discussed at the summit, one of the key advantages is that
ra_serf would allow us to do full commit parallelization *if* the
backend FS supported it. That's just wicked cool and would be hard to
do within ra_dav. With multiplexed connections, if you couple ra_serf
with a set of read-only load balanced mirrors (a la dav-mirror or
Google Code's Bigtable backend), you get *much* better server scaling
characteristics as well. ra_serf opens us up to dumber server-side
caches that don't need a local repository to operate.
Plus, Serf is not under LGPL - which is a blocker for Subclipse moving
to Eclipse, AIUI.
So, while client-side performance is an important consideration, I
don't view it as the only one.
Note that the one bug that I can't really do much here to fix is that
Google Code's Project Hosting doesn't work with ra_serf. It's a known
bug on Google's end - not much I can do within this forum to fix that.
=P
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 25 04:09:30 2006