On 25-Feb-08, at 1:02 AM, Chris Rose wrote:
> 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 :)
...which would again point to the client as the bottleneck?
—Toby
>
> 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
>
Received on 2008-02-25 17:22:38 CET