FreeBSD restartable send/receive over WAN

[Matthew Seaman]

On 03/03/2017 00:34, Shiva Bhanujan wrote:
> I ran the same set of tests between 2 FreeBSD instances, connected
> on a 1G LAN. The the comms was setup using mbuffer. Here's the basic command.
> 
> time zfs send -v <snapshot> | <compress> | mbuffer -O <IP>:8099 -b 1024 -m 128M -P 10 -q -l /tmp/mbuffer.log
> mbuffer -4 -I 8099 -b 1024 -m 128M -q -l /tmp/mbuffer.log | <uncompress> | zfs recv <snapshot>
> 
> Here are the results that I got.
> 
> no compression:
> real    3m18.591s
> user    0m0.390s
> sys     0m8.177s
> 
> xz -0:
> real    7m26.349s
> user    7m6.436s
> sys     0m8.471s
> 
> pxz -0:
> real    2m28.470s
> user    6m44.168s
> sys     0m12.002s
> 
> gzip:
> real    3m12.482s
> user    3m8.260s
> sys     0m4.974s
> 
> lz4:
> real    1m58.363s
> user    0m10.000s
> sys     0m8.708s
> 
> 
> 
> lz4 still comes out best.  Is there anything else that I might be
> missing in my tests?  don't have a real setup at this time to test
> WAN connections, but I'd like to think that these results can be
> extrapolated to a WAN link also.
> 

lz4 has the very interesting property that it will detect when it is
taking too long to compress any particular block[*] and instead just
pass the block through uncompressed.  It trades off compression for speed.

The results you're seeing here on a reasonably high-bandwidth, low
latency connection show that the time spent compressing the data is a
significant part of the total, so lz4's short-cutting has a big benefit.

If you were trying to transmit over a lower bandwidth connection, you'ld
find that the share of elapsed time due to doing the compression was
quite a bit less, and in that case a compression algorithm that tried
harder and achieved better actual compression would give a faster
overall result by sending less data over the wire.  You would also not
necessarily need to parallelize the compression over so many cores in
order to keep a small pipe continually filled up.

Or, in other words, you need to do your tests under the conditions you
will be using in production in order to get completely reliable results.

	Cheers,

	Matthew





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20170303/f1b3792d/attachment.sig>