[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: mod_dav_svn performance

From: Mark Phippard <markphip_at_gmail.com>
Date: Sun, 24 Feb 2008 19:27:27 -0500

On Sun, Feb 24, 2008 at 7:11 PM, Chris Rose
<chris.rose_at_messagingdirect.com> wrote:
> Waittaminute... _client_ IO is the issue? That doesn't make sense; we're
> using a variety of clients ranging from modern Windows and Linux laptop and
> Desktop machines to Solaris 8 build servers, and they're all slow; I'm not
> discounting it, but it seems to me that the problem in our case might be
> more centralized.
>
> That said, I'll look into the server-side I/O issues, too. The machine
> hosting the repository is using RAID and some kind of high-end storage that
> I don't directly deal with; I'll pester our sysadmin to look into it.
>
> Thanks for the input. Anyone else? :)

Checkout is probably the worst operation to benchmark. Subversion
writes out twice as much client-side data as CVS, so unless your
network or server is a big bottleneck, it would be expected for
checkout to be much slower than CVS. Also, how often are you doing
checkout, compared to update and commit. These are the operations
where Subversion shines, not to mention the client-only features like
diff and revert.

There is nothing you can do to make checkout in Subversion as fast as
CVS. As Erik pointed out, using the ra_serf library might offer a
small boost. Using svnserve instead of mod_dav_svn offers a definite
boost. In either case, it should still be slower than CVS though.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-25 01:27:45 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.