Calum Mackay

Thursday December 11, 2008

ssh/scp: poor performance when using session sharing

For a long time I've been using ssh session sharing, by setting these options:

diz $ cat ~/.ssh/config
Host *
 ControlMaster auto
 ControlPath /tmp/%r@%h:%p

This tells an initial ssh client to create a "master" connection to the remote server, and also to create and listen on a socket, All subsequent clients use that socket, if available, to connect to the remote server, thus re-using the master's connection, and not create a new ssh connection themselves.

There are a number of theoretical advantages to session sharing: it requires only one per-session cryptographic setup, which would be useful if using lots of separate connections on a slow system. It also, and for the same reason, means you only have to enter your credentials once.

On a fast system, and using an authentication agent, these advantages are less relevant.

Sadly, I've just noticed that it also potentially introduces a performance impact.

Today I was transferring some large files from my laptop to my home server, via scp (ssh) over gigabit ethernet. Somewhat surprised to see a disappointing rate of around 50Mb (Mega bits) per second. Somehow, I'd hoped for a little more from gigabit ethernet.

I also noticed a large cpu usage coming from an otherwise innocuous ssh process, handling a simple login to the laptop, which wasn't even being used. Attempting to logout from this session, which just sat there, reminded me of the session sharing: this session must be the master, and that can't exit whilst others are using "its" connection.

Killing off the master, and restarting the scp, suddently boosted the transfer to a maximum of 175Mbps; a three-fold improvement.

So, it appears that using ssh session sharing is not a good idea for large transfer, where performance is important. It remains to be seen whether it's useful in other situations.

It also remains to be seen why I'm still only getting 175Mbps over gigabit eth.

[testing done using OpenSSH_5.1p1 at both ends, Debian & Unbuntu Linux; "-o Compression=no"]