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
>> > starts a new repository session (network connection) once for each
>> > target of the command. In our case the problem was with 'svn
>> > but I think it applies to almost anything. The performance became
>> > dominated by ~2-3 seconds per target overhead each time it made a
>> > 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
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-06 00:50:58 CET