Re: mod_dav_svn performance

I suppose this is true, but the wide range of client environments in
which I've seen this suggests something else. Probably network. And,
I assume, svn only sends one copy over the wire :)

It might be a latency issue in the network; we've got a few other
issues like that. Given the higher count of roundtrips that would
make sense.

Thanks, guys!

On 24-Feb-08, at 6:37 PM, Mark Phippard wrote:

> On Sun, Feb 24, 2008 at 7:59 PM, Matt Sickler
> <crazyfordynamite_at_gmail.com> wrote:
>>
>> On Sun, Feb 24, 2008 at 6:27 PM, Mark Phippard <markphip_at_gmail.com>
>> wrote:
>>
>>
>>> 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.
>>
>> why would the network have to transfer any more data than CVS?
>> Wasn't SVN
>> designed to use the network most effectively?
>
> SVN probably sends less data over the network than CVS, although
> perhaps not when using HTTP. What I was saying was that unless you
> have a really slow network connection, then the client side processing
> is going to be the biggest determinant of performance. IOW, I was
> trying to answer your question as to why it is the client that would
> matter for performance.
>
> --
> 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
>

-- 
Chris Rose
Developer    Planet Consulting Group
(780) 577-8433
crose_at_planetci.com