Dec 16, 2006

ssh compression can slow you down

[I've reposted this post on ssh compression to my new blog as I keep using it myself]

When copying some large files between hosts at our rack I noticed some pretty poor transfer speeds. Having recently forked out $70 for a rack mount gigabit switch I wondered what was slowing things.

It seems ssh was trying to help out by compressing everything however compressing the data took more than twice as long as transferring the uncompressed data. I proved this by disabling compression at the commandline and seeing the transfer speed more than triple.

mbailey@modu1:~/vm$ scp -r r03 modu4:vm/
Ubuntu 64-bit-f001.vmdk 7% 147MB 8.1MB/s 03:54 ETA

mbailey@modu1:~/vm$ scp -r -o 'Compression no' r03 modu4:vm/
Ubuntu 64-bit-f001.vmdk 100% 2048MB 28.1MB/s 01:13 ETA

So how can we put this into practice everywhere?

Setting 'Compression no' in /etc/ssh/ssh_config will do the trick for me. There's no need for my vmware hosts to be compressing files I copy between them. I do want compression when copying files over shared/slower links but I can achieve that by initiating connections that benefit from compression on boxes that are configured to use it.

If I want to enable compression I can always use the '-C' switch to enable compression.

6 comments:

Unknown said...

I bet it's not that the file is large - but that it's already compressed.

A way to test this would be to repeat the transfer with a large compressible (like text?) file.

plaukas pyragely said...

You could also use "-c arcfour" option for faster cipher. Combined with disabled compression, bziped2 mysql dumps fly compared to ssh with default options.

Unknown said...

The best option, though, would be to use Host sections to define the faster hosts where you want compression disabled, leaving everything else (everything on the other end of slow(er) connections) set to compress. It of course may benefit from case-by-case enable/disable (such as enable for uncompressed, disable for already-compressed), but if you expect to be using SSH primarily in one situation or the other, you can still set sane defaults and override them later.

Unknown said...

First of all thank you sharing the tip.

I have tried transferring file of size 2.5 GB to a remote server with and without compression but the time it took for two methods was almost same.

With out compression - 2 min 42 sec
With compression - 2 min 53 sec

Petar Bear said...

As per the manpage, rsync compression is more efficient than ssh compression. Definitely not very useful to do both, especially on slower systems. To explicitly turn off ssh compression and turn on rsync compression from the command line, use these options:
rsync --compress-level=1 \
--rsh="ssh -c arcfour256 -o 'Compression no'"

When transferring over a fast network or to a slow host, I like to ionice/nice the receiving rsync:
rsync --rsync-path="ionice -c 3 nice rsync"

References:
arcfour256 and arcfour128 tested slightly faster than arcfour, much faster than others
https://blog.famzah.net/2010/06/11/openssh-ciphers-performance-benchmark/

sadhanagager said...

Casino Rewards | JamBase
All your favorite casino games, including 제주도 출장안마 slots, table games and video poker. If you're looking for a 양산 출장안마 way to 파주 출장마사지 get comps and benefits, 삼척 출장샵 we've 경기도 출장마사지 got you covered.