j'ai du récemment faire des tests avec rsync pour savoir quel était le moyen de l'utiliser qui allait utiliser le moins de temps (et donc de bande passante) possible.
Le but est d'envoyer régulièrement des fichiers textes qui changent souvent mais peu (des dumps .sql). Alors faut-il les envoyer en .sql ou en .sql.gz? Et chez nous, nous utilisons la compression de rsync (-z) pour les transferts via internet mais pas pour les transferts sur le LAN (switch gigabit).
Aussi, j'ai entrepris de faire quelques tests avec et sans compression, en envoyant un fichier puis sa version un peu modifiée (dumpée qques heures plus tard). J'ajoute que le test a été fait sur des machines debian stable 4.0 etch, avec rsync version 2.6.9 protocol version 29. J'ai utilisé deux fichier de taille différentes:
- 1.sql de 18986153 octets
- 2.sql de 38907957 octets
- 1.sql de 974669 octets, soit ~5% de l'original
- 2.sql de 5622484 octets, soit ~15% de l'original
- 1.sql de 1052710 octets, soit ~108% de l'autre gz
- 2.sql de 5804575 octets, soit ~103% de l'autre gz
Voyons maintenant quel est le speedup et combien d'octets sont envoyés au second envoi.
Sans compression rsync (-av):
- 1.sql 278.19; 42028 sent
- 2.sql 33.33; 1123604 sent
- 1.sql.gz 10.72; 84947 sent
- 2.sql.gz 1.33; 4209490 sent
- 1.sql.gz (avec --rsyncable) 31.02; 27728 sent
- 2.sql.gz (avec --rsyncable) 8.06; 706105 sent
Ici, on le voit, le meilleur moyen est d'utiliser un .gz avec --rsyncable. Pour autant que la bande passante soit une priorité tout en utilisant pas la compression rsync (-z).
Plus intéressant, voyons les mêmes tests, avec la compression rsync (-avz):
- 1.sql 602.18; 5309 sent
- 2.sql 198.33; 152437 sent
- 1.sql.gz 11.16; 81335 sent
- 2.sql.gz 1.33; 4208162 sent
- 1.sql.gz (avec --rsyncable) 35.16; 23730 sent
- 2.sql.gz (avec --rsyncable) 8.14; 698166 sent
Là, il n'y a pas photo, l'utilisation de fichiers gzippés augmente considérablement la taille du transfert! L'option --rsyncable réduit bien le transfert par rapport au .gz normal, mais le .sql est largement devant.
Notons aussi que, compression rsync (-z) ou pas, l'envoi d'un .gz normal est quasi identique; il renvoie quasi tout le fichier dans les deux cas.
Moralité : faut pas envoyer des .gz de fichiers texte en utilisant la compression rsync, cela rallonge drôlement la taille et donc le temps du transfert.
# merci
Posté par tfeserver tfe (site web personnel) . Évalué à 5.
# surcompression
Posté par ZeroHeure . Évalué à 2.
logiquement le fchier devient plus gros...
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: surcompression
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 1.
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: surcompression
Posté par fcartegnie . Évalué à 2.
Un --whole-file devrait ne transmettre que la liste des fichiers.
# Variation
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je pense que cela devrait être le moins consommateur de bande passante.
"La première sécurité est la liberté"
[^] # Re: Variation
Posté par guppy . Évalué à 10.
Ce que tu viens de décrire doit être en gros ce que fait rsync.
[^] # Re: Variationrs
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
De plus, la compression utilisé est gzip, légère mais bien moins efficace que lzma.
Bref, dans ce cas, cela me parait bien plus optimal pour ce cas d'utilisation.
"La première sécurité est la liberté"
[^] # Re: Variationrs
Posté par foulmetal canette (site web personnel) . Évalué à 2.
En fait, le comportement par défaut de rsync c’est de regarder la date et/ou la taille du fichier pour voir la différence. Une option supplémentaire spécifie si l’on veut faire une différence sur les checksums : ça à l’avantage d’être plus fiable mais au détriment de la vitesse.
[^] # Re: Variation
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Oui.
> Ce que tu viens de décrire doit être en gros ce que fait rsync.
Pas tout à fait. La difficulté de rsync, c'est qu'il ne veut envoyer que le patch, mais que pour calculer le diff correctement, il faudrait avoir les deux copies sur la même machine, et ça, justement, c'est ce qu'on cherche à faire. Du coup, rsync se débrouille en coupant le fichier en morceaux, envoyant les checksums des différents bouts, ... mais c'est quand même sous-optimal.
Une solution qui fait des diffs en local, et qui envoie le patch, ça existe déjà aussi, c'est ce que fait à peu près n'importe quel gestionnaire de versions. Donc, une solution assez simple serait d'utiliser par exemple Git, un commit sur la machine distante, un "pull" et le tour est joué.
[^] # Re: Variation
Posté par windu.2b . Évalué à 1.
Alors que pour un SVN/Git/whatever, la copie de travail locale garantit cela.
[^] # Re: Variation
Posté par wismerhill . Évalué à 2.
[^] # Re: Variation
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
[^] # Re: Variation
Posté par wismerhill . Évalué à 1.
Ça veut dire que pour les autres il faut prévoir le double de place pour la copier locale?
[^] # Re: Variation
Posté par windu.2b . Évalué à 2.
La copie locale occupe autant de place que le dépôt sur le serveur (modulo les différences, locales ou distantes, apportées depuis la dernière synchronisation).
[^] # Re: Variation
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Pour Git, par exemple, c'est carrément tout l'historique qui est dupliqué en local, mais suffisament bien compressé pour prendre en général moins de place que l'arbre de travail.
En pratique, en général, on s'en fout un peu : l'arbre de travail est un truc qui n'a pas besoin de beaucoup d'attention au niveau sauvegarde, et vu le prix des disques durs, ... (par contre, l'archive, elle, elle est stoquée sur des disques qui coûtent cher en général, et on est bien content qu'elle soit compressée comme il faut).
[^] # Re: Variation
Posté par windu.2b . Évalué à 2.
Parce que moi, c'est ainsi que j'ai compris la question !
[^] # Re: Variation
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Sur le serveur, tu as 1 copie de ce fichier, dans la seule révision. Le dépôt fera ~2Mo. Dans la copie locale, tu as le fichier sur lequel tu travailles, plus le fichier base caché dans un .svn/, donc tu as le fichier en double.
Testé à l'instant :
$ du -sh *
3.8M checkout
2.0M repo
$ du -sh checkout/dsc04507.jpg checkout/.svn/text-base/dsc04507.jpg.svn-base
1.9M checkout/dsc04507.jpg
1.9M checkout/.svn/text-base/dsc04507.jpg.svn-base
# Pas tout compris
Posté par mekare . Évalué à 3.
J'aurais besoin de quelques éclaircissements sur les valeurs indiquées. Exemple :
# 2.sql.gz 1.33; 4209490 sent
le 1.33 represente-t-il ne nombre de secondes ?
Si oui, cela veut dire (si j'ai compris) que le transfert est plus important avec un gzip classique mais plus rapide, et que le gzip --rsyncable. et que le gzip --rsyncable est plus léger mais plus long...
Maintenant, si j'ai juste je me demande quelle peut-être l'utilisation CPU lors des différentes opérations, aussi bien côté client que serveur.
(Et si j'ai rien compris du tout, peux-tu m'aider à comprendre)
[^] # Re: Pas tout compris
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 4.
Côté charge CPU, ajouter de la compression à rsync (-z) fait naturellement monter le load sur *les deux machines* car il faut compresser d'un côté et décompresser de l'autre. C'est pourquoi je mettais que, chez nous en tous cas, nous n'utilisons pas cette compression pour les transferts internes car le gain en bande passante est moins plus que gâché par la charge CPU.
Note que nous ne payons naturellement pas la bande passante à l'interne. Par contre, pour les transferts via internet, nous la payons; c'est pourquoi nous recherchons une efficacité de ce côté.
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: Pas tout compris
Posté par mekare . Évalué à 1.
[^] # Re: Pas tout compris
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 2.
La gelée de coings est une chose à ne pas avaler de travers.
# rsync 3 protocol v30
Posté par Benjamin (site web personnel) . Évalué à 2.
ce backport requiert les packages de lenny base-file et rsync. très léger.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.