Performance Tuning

What actually limits speed

On a 10GbE LAN, rsync's defaults rarely hit wire speed. Three things bottleneck in practice: encryption CPU, compression CPU, and per-file metadata overhead. Tuning each squeezes another chunk of throughput.

Drop compression on fast LAN

-z moves the bottleneck from network to CPU as soon as your network is faster than ~100 Mbit/s. On 10GbE, -z can halve throughput. Drop it. Keep it only on actual slow/metered links.

Pick a fast cipher

Modern OpenSSH defaults are fast on Apple Silicon and modern x86. If you're on older hardware, force a hardware-accelerated cipher with -c aes128-gcm@openssh.com via -e ssh -c ....

10GbE expectations

Network	Theoretical	Real-world rsync
1 GbE	125 MB/s	~100–110 MB/s
10 GbE	1.25 GB/s	~800 MB/s – 1.1 GB/s
Thunderbolt Bridge (Mac↔Mac)	~5 GB/s	~1–3 GB/s (disk-limited)

If your iperf3 (Track 5) shows close to wire speed but rsync doesn't, the bottleneck isn't the network — it's rsync's per-file overhead, encryption CPU, or disk.

Code

Throughput knobs·bash

# Fast LAN — no compression, modern cipher
rsync -av --progress source/ host:/dest/

# Force a fast cipher (hardware-accelerated AES-GCM)
rsync -av --progress -e "ssh -c aes128-gcm@openssh.com" source/ host:/dest/

# WAN — keep compression
rsync -avz --progress source/ remote:/dest/

# Throttle on a metered link
rsync -av --bwlimit=10000 source/ remote:/dest/   # 10 MB/s cap

# Tar pipe with fast cipher beats rsync on tiny-file storms
tar cf - source | ssh -c aes128-gcm@openssh.com host 'tar xf - -C /dest/'

Exercise

On your fastest available LAN connection, run iperf3 (Track 5 has the setup) to find your raw network ceiling. Then run a real rsync of a couple-GB directory both with and without -z. Compare to the iperf3 ceiling. The gap is your overhead — usually disk or encryption. That's where future optimization belongs.