tl;dr Over slow transfer links, compress, otherwise don't. Below is a compression speed test, a link to a bandwidth conversion tool and some info.
Using compression with
rsync will only speed things up if the intermediate link is "slow enough", i.e. if the machine in one end is able to produce a compressed data stream quick enough to saturate the communication link.
So, what's the slowest link at which I should use compression to gain anything?
The following is a very unscientific test, which will show how quickly
gzip can produce data, and what that means for whether you should compress your network bulk transfers in general.
The input data will change the outcome of the test greatly. I'm using an uncompressed (!) regular file on my computer which may be representative of the type of data I usually transfer over networks. Using
/dev/zero (producing unlimited zeroes) would be misleading as a stream of zeroes would be very easy to compress, and using
/dev/random would be misleading for the opposite reason. So instead I use a tar file of my
$HOME/local directory, which contains software I've installed in my
$HOME. The file is uncompressed in itself, but contains a mix of binary files, small compressed files and source/text files, and would I compress it with default setting for
gzip it would shrink by 67% from 64 MiB to 22 MiB.
$ gzip -c local.tar | dd of=/dev/null
43092+4 records in
43093+1 records out
22063854 bytes transferred in 2.819 secs (7825741 bytes/sec)
I do this a few times to get a feeling for what the average might be, and it comes to about 7800000 bytes/s.
Then I use a network bandwidth calculator to see what this converts into. In this particular case, it happens to be just under the capacity of a "100Mb Ethernet" wired link, just faster than a "VDSL Download" internet uplink, slightly quicker than a "802.11[a/g]" wireless link, and somewhere in-between "Bluetooth v3.0" (slower) and "USB 2.0" (faster).
This means that if I'm using compression over anything faster than that, compression will likely slow down the transferring of the file.
rsync might not be using the exact same libraries as
gzip to do compression, but the above would give you a bit of a hint at least.
rsync does more than compression though, as you know, and the real speed increase comes from only transferring [bits of] files that have changed.
In my own experience, using compression with
rsync has become less and less beneficial over the last 10 years or so, as the bandwidth of the networks have increased (where I am).
For doing incremental backups, I would definitely recommend investigating the
--link-dest option (this has nothing to do with what's transferred, only with how things are stored at the target). Also, if you're doing it over SSH, don't use compression if your SSH connection is already compressed, and only compress SSH connections (tunnels etc.) that are over slow links, for the same reasons as above.