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

TSVN treating repo connections as free greatly reduces the responsiveness of svn+ssh protocol

From: Ryan Rutledge <ryandrutledge_at_gmail.com>
Date: Sat, 26 Sep 2015 11:48:50 -0700

TLDR: TSVN over svn+ssh protocol uses multiple connections in succession,
opening and closing each one in various steps. A simply repo browse
operation typically uses about 6 discrete sessions, rather than establishing
a single session and using that. This causes a long delay for nearly any
operation in TSVN when it takes a second to authenticate the SSH key, which
happens multiple times for every operation. Can TSVN be made to reuse a
single session (within some short time frame) instead?


FULL: I've recently migrated from CloudForge to our own server that uses SSH
key authentication. Connecting to CloudForge with https always had a couple
second delay to repo browse, etc., but now that delay is several seconds
long over svn+ssh on our new server. Digging into /var/log/auth.log, I see
that the SSH key is being validated, then closed, then revalidated, then
closed, and so on about 6 different times for just a repo browse operation
in TSVN. This makes Pageant or a similar key caching tool all but mandatory,
otherwise you are prompted for your private key passphrase 6 times, once for
each connection (confirmed after closing Pageant - I thought it wasn't
working because it kept prompting my for the passphrase over and over, but
then after the 6th it worked). In essence repo connections are treated as a
trivially cheap resource, which is surely true on the local file system or a
LAN, but far from true for SSH key-based authentication. This is discussed
briefly here:


I attempted to use the "ControlMaster" approach to cause the first session
to be reused for a short time, but It appeared to have no effect (possibly
due to my own error - it never seemed to create the ControlPath file at
all). It seems like it should be possible to either reuse the connections
internally in TSVN, or automate creating one tunnel to the host then
directing SVN traffic to the tunnel opening on the client end (perhaps those
are the same solution).


Best regards,

Ryan Rutledge


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-09-28 12:09:56 CEST

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

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