tl; dr Sur les liaisons de transfert lentes, compressez, sinon ne le faites pas. Vous trouverez ci-dessous un test de vitesse de compression, un lien vers un outil de conversion de bande passante et des informations.
Utilisation de la compression avec rsync n'accélérera les choses que si le lien intermédiaire est "suffisamment lent", c'est-à-dire si la machine d'un côté est capable de produire un flux de données compressé assez rapidement pour saturer le lien de communication.
Alors, quel est le lien le plus lent sur lequel je devrais utiliser la compression pour gagner quelque chose?
Ce qui suit est un test très peu scientifique, qui montrera à quelle vitesse gzippeut produire des données, et ce que cela signifie pour savoir si vous devez compresser vos transferts en masse sur le réseau en général.
Les données d'entrée changeront le résultat du test beaucoup . J'utilise un fichier normal non compressé (!) Sur mon ordinateur, qui peut être représentatif du type de données que je transfère habituellement sur des réseaux. Utiliser /dev/zero(produire des zéros illimités) serait trompeur dans la mesure où un flot de zéros serait très facile à compresser, et utiliser /dev/randomserait trompeur pour la raison opposée. J'utilise donc à la place un fichier tar de mon $HOME/localrépertoire, qui contient les logiciels que j'ai installés dans mon $HOME. Le fichier est non compressé en lui-même, mais contient un mélange de fichiers binaires, de petits fichiers compressés et de fichiers source / texte. Si je le compressais, le réglage par défaut gzipréduirait de 67%, passant de 64 à 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)
Je fais cela plusieurs fois pour avoir une idée de ce que pourrait être la moyenne, ce qui représente environ 7800000 octets / s.
Ensuite, j'utilise un calculateur de bande passante réseau pour voir en quoi cela se transforme. Dans ce cas particulier, il se trouve qu’elle est juste inférieure à la capacité d’une liaison filaire "100Mb Ethernet", juste plus rapide qu’une liaison montante Internet "VDSL Download", légèrement plus rapide qu’une liaison sans fil "802.11 [a / g]", et quelque part entre "Bluetooth v3.0" (plus lent) et "USB 2.0" (plus rapide).
Cela signifie que si j'utilise la compression sur quelque chose de plus rapide , la compression ralentira probablement le transfert du fichier.
rsyncn'utilise peut-être pas exactement les mêmes bibliothèques que gzippour la compression, mais ce qui précède vous donnerait au moins un indice.
rsyncComme vous le savez, la compression ne se limite pas à la compression et l’ augmentation de la vitesse réelle provient uniquement du transfert de [fichiers de] fichiers qui ont été modifiés.
Selon ma propre expérience, l’utilisation de la compression avec rsyncest devenue de moins en moins utile au cours des 10 dernières années, à mesure que la bande passante des réseaux a augmenté (là où je suis).
Pour les sauvegardes incrémentielles, je recommanderais certainement d’examiner cette --link-destoption (cela n’a rien à voir avec ce qui est transféré, mais seulement avec la façon dont les choses sont stockées sur la cible). De même, si vous le faites sur SSH, n'utilisez pas la compression si votre connexion SSH est déjà compressée et ne compressez que les connexions SSH (tunnels, etc.) via des liaisons lentes, pour les mêmes raisons que ci-dessus.
