tl; dr低速転送リンクでは圧縮し、そうでない場合は圧縮しません。以下は、圧縮速度のテスト、帯域幅変換ツールへのリンク、およびいくつかの情報です。
で圧縮を使用するとrsync
、中間リンクが「十分に遅い」場合、つまり、一方のマシンが通信リンクを飽和させるのに十分な速さで圧縮データストリームを生成できる場合にのみ速度が上がります。
それで、圧縮を使用して何かを得る必要がある最も遅いリンクは何ですか?
以下は非常に非科学的なテストであり、gzip
データを生成する速度と、ネットワークのバルク転送を一般的に圧縮する必要があるかどうかを示すものです。
入力データは、テストの結果を大きく変えます。私は通常、ネットワーク経由で転送するデータのタイプを表す可能性がある、コンピューター上の非圧縮(!)通常ファイルを使用しています。/dev/zero
ゼロのストリームは非常に圧縮しやすいため、使用(無制限のゼロを生成)は誤解を招く可能性があり/dev/random
、逆の理由で使用は誤解を招く可能性があります。代わりに、$HOME/local
ディレクトリにインストールしたソフトウェアを含むディレクトリのtarファイルを使用します$HOME
。ファイル自体は圧縮されていませんが、バイナリファイル、小さな圧縮ファイル、およびソース/テキストファイルが混在しており、デフォルト設定で圧縮するとgzip
64 MiBから22 MiBに67%縮小します。
$ 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)
私はこれを数回繰り返して、平均が何であるかを確認します。これは約7800000バイト/秒になります。
次に、ネットワーク帯域幅計算機を使用して、これが何に変換されるかを確認します。この特定のケースでは、「100Mbイーサネット」有線リンクのキャパシティの下にあり、「VDSLダウンロード」インターネットアップリンクよりも高速で、「802.11 [a / g]」ワイヤレスリンクよりもわずかに高速で、どこかで「Bluetooth v3.0」(低速)と「USB 2.0」(高速)の間。
これは、それよりも高速で圧縮を使用している場合、圧縮によりファイルの転送が遅くなる可能性が高いことを意味します。
rsync
圧縮を行うのとまったく同じライブラリを使用していない可能性がありますgzip
が、少なくとも上記のヒントを参照してください。
rsync
ただし、ご存知のように、圧縮以上のことを行います。実際の速度向上は、変更された[ビット数]のファイルのみを転送することで実現されます。
私自身の経験でrsync
は、ネットワークの帯域幅が増加するにつれて(私がいるところで)、圧縮の使用は過去10年ほどで益々少なくなりました。
増分バックアップを行うには、--link-dest
オプションを調査することをお勧めします(これは、転送されるものとは関係なく、ターゲットでの格納方法とのみ関係があります)。また、SSH経由で行う場合は、SSH接続が既に圧縮されている場合は圧縮を使用せず、上記と同じ理由で、低速リンク経由のSSH接続(トンネルなど)のみを圧縮します。