Date: Fri, 3 Mar 2017 08:54:58 +0000 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-fs@freebsd.org Subject: Re: FreeBSD restartable send/receive over WAN Message-ID: <a7ecaead-0eb3-c3a1-e410-302e4e00498d@FreeBSD.org> In-Reply-To: <3A5A10BE32AC9E45B4A22F89FC90EC0701BDB12ABA@QLEXC01.Quorum.local> References: <0719669324a44fe0bfba3e8e08b0ae99@exch2-4.slu.se> <3A5A10BE32AC9E45B4A22F89FC90EC0701BDB12619@QLEXC01.Quorum.local> <op.ywdyg82mkndu52@53556c9c.cm-6-6b.dynamic.ziggo.nl> <3A5A10BE32AC9E45B4A22F89FC90EC0701BDB12ABA@QLEXC01.Quorum.local>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xw4cGOax3qTBV1jbnD20AnRnOHHoa5BLd Content-Type: multipart/mixed; boundary="ixmpcKQ2u5Ur6Nsm5AJB6VuUNd57gn5RA"; protected-headers="v1" From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-fs@freebsd.org Message-ID: <a7ecaead-0eb3-c3a1-e410-302e4e00498d@FreeBSD.org> Subject: Re: FreeBSD restartable send/receive over WAN References: <0719669324a44fe0bfba3e8e08b0ae99@exch2-4.slu.se> <3A5A10BE32AC9E45B4A22F89FC90EC0701BDB12619@QLEXC01.Quorum.local> <op.ywdyg82mkndu52@53556c9c.cm-6-6b.dynamic.ziggo.nl> <3A5A10BE32AC9E45B4A22F89FC90EC0701BDB12ABA@QLEXC01.Quorum.local> In-Reply-To: <3A5A10BE32AC9E45B4A22F89FC90EC0701BDB12ABA@QLEXC01.Quorum.local> --ixmpcKQ2u5Ur6Nsm5AJB6VuUNd57gn5RA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 co= mmand. >=20 > 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> >=20 > Here are the results that I got. >=20 > no compression: > real 3m18.591s > user 0m0.390s > sys 0m8.177s >=20 > xz -0: > real 7m26.349s > user 7m6.436s > sys 0m8.471s >=20 > pxz -0: > real 2m28.470s > user 6m44.168s > sys 0m12.002s >=20 > gzip: > real 3m12.482s > user 3m8.260s > sys 0m4.974s >=20 > lz4: > real 1m58.363s > user 0m10.000s > sys 0m8.708s >=20 >=20 >=20 > 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. >=20 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= =2E 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 --ixmpcKQ2u5Ur6Nsm5AJB6VuUNd57gn5RA-- --Xw4cGOax3qTBV1jbnD20AnRnOHHoa5BLd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJYuS9iXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATflwQAI9UqV7n0Ucrcok3lyZlvEW+ /M2fMG99bfqct3VF/hoW+xb6jYQeaZF3O+rJCNj1ZeYqbnVtyjKnhSYXZGBA3oG1 uk6oC00ifMtTrf5P3+BbgUSKTaRhjnyfFu+Ukf0qyFMieSNHbPwxF5Y3FwFrn6eu tU9jKzUTZyRzL4vy5JsPQ8abo0WSQLSeGlob90upq4/RtyIAxGeLte5NGU9kLs14 kMLDess+O7SRqYfN8/aZ6QhBjFFEgm5jn8yH+go9SLLEzWUjlukCp2jLmk5xCoka nUpec4S0ix1n3gPG3C+pzwOWw9jvkMJGiI25ltUZLxhACmDixCv/JQPZ72udCmQd bxY3LrT81IYW1gNm3OeVwWLNmTpGlgEbLrbU9GPyCzBs7/7pG94Ems8Y7Q6zAz1w kl5L4Oc+pqeBc9sPbx37rKYiFcEizaOaujWszm92NpvNE1Y/oPKu2rsbSXl1gqZA muZ6I4cbmUJHmP4VK148YEsOEURLO8nnW+pJo+lcDxoH3b9vhb0nWk/xY6HVxgr/ kapM8wkwqShPr9WeB0OjvrIE7nQagHUTbFz0vyt/d2+biRCnyzZbKzjlQjSSha6L Xa8HWC0t1omsxqMxv2yANyFpPTfHRhl1Uc/DLP+i2lrnbF/95rwXK2eUnmLJ12nQ gz3aDpBlFPXlV50wVgAV =pKS+ -----END PGP SIGNATURE----- --Xw4cGOax3qTBV1jbnD20AnRnOHHoa5BLd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a7ecaead-0eb3-c3a1-e410-302e4e00498d>