Hi
Thanks for the replies.
We're using svnserve (which based on some replies I got is a good
thing).
Our repository is on one machine and svnserve runs (as a windows
service) on another machine (same network) using a mapped network drive
to the repository. Svnserve must run on the second machine because it
has a fixed IP and is accessible through the firewalls to our various
clients. The repository was installed on the other machine mainly
because of backup etc reasons, but in theory it could be moved to the
machine running svnserve (would this introduce a significant performance
gain?). We're mainly using IP addresses for referencing so DNS is not a
real issue.
I definitely also saw the additional delay introduced with multiple
transactions. Below are 2 ways of getting exactly the same thing.
However the first give all the results followed by a single "Status
against revision X" message where the second will give the "Status
against revision X" for each individual file. To me this indicates some
additional handshaking? When on the same network as the repository,
this is a non issue, but when on a remote connection (e.g. using VPN
from home) this can make the difference between a 30 second and a 190
second transaction.
Svn status --show-updates --verbose -N c:\my-files
Svn status --show-updates --verbose c:\my-files\*.*
Regards
Niel
-----Original Message-----
From: news [mailto:news_at_ger.gmane.org] On Behalf Of Vincent Tondellier
Sent: 06 January 2008 01:51
To: users_at_subversion.tigris.org
Subject: RE: Re: Faster SVN Status
Harvey, Edward wrote:
> I can't say exactly what's happening in Niel's situation, but I
support
> a company with worldwide network, and when we SSH from Boston to India
> or vice-versa, there is a few second delay. Because there's a 250ms
> ping response delay, and the initial ssh handshake is the equivalent
of
> 10-15 small packet round-trips, it's about 5-6 seconds before the
> command prompt appears.
>
> If you use svn:// protocol and svnserve, there's just the basic tcp
> handshake before useful data starts going across, so it's much faster.
> Call it 1-2 x the ping delay. About a half a second for me.
>
> If you use https://, it looks like something like half a dozen small
> packet round trips. In my case, about 2 seconds delay. So it's
faster
> than svn+ssh, but not as fast as svnserve.
>
You should try the connection caching feature of OpenSSH, it only
establish
one master ssh connection, and opens new ssh "channels" for each new
connection you make. The GCC wiki have some explanations on this :
http://gcc.gnu.org/wiki/SSH connection caching
>> -----Original Message-----
>> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
>> Sent: Friday, January 04, 2008 10:42 AM
>> To: Steven Bakke
>> Cc: Niel De Clerk; users_at_subversion.tigris.org
>> Subject: Re: Faster SVN Status
>>
>> Steven Bakke wrote:
>> >
>> > However through profiling we found a performance bottleneck in that
>> it
>> > starts a new repository session (network connection) once for each
>> > target of the command. In our case the problem was with 'svn
>> update',
>> > but I think it applies to almost anything. The performance became
>> > dominated by ~2-3 seconds per target overhead each time it made a
> new
>> > svn+ssh connection to the server.
>>
>> What can possibly cause a several-second delay? Does your reverse
DNS
>> lookup resolve quickly? Are IDENT queries dropped and timing out?
>>
>> --
>> Les Mikesell
>> lesmikesell_at_gmail.com
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
This email is subject to our email legal notice, to view browse to http://www.angloplatinum.co.za/E-mailLegalNotice/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-07 06:21:46 CET