Dans l'exemple c'est sqlplus d'oracle mais c'est valable aussi pour mysql et certainement beaucoup d'autres.
En fait ça fonctionne avec n'importe quelle commande pipable.
C'est d'ailleurs quelque chose qui m'a sauvé des heures (et des points de santé mentale) dans le passé en transférant des fichiers via tar+ssh au lieu de scp. Aujourd'hui, avec le binaire rsync disponible de manière standard sur la plupart des serveurs, l'intérêt serait plus limité. Ça peut rester pertinent quand la source et la destination sont distantes par exemple.
J'allais écrire que c'est dû à la compression et que ça fonctionne bien notamment pour des données faiblement compressées et/ou les connexions lentes, mais finalement après avoir fait des tests, il se trouve que le fait de compresser ou pas n'a pas une incidence majeure. Mais utiliser tar+ssh ou rsync est infiniment plus efficace que scp.
Je ne m'explique pas pourquoi scp (même compressé) est à ce point si lent par rapport à la concurrence (bien pire que dans ma mémoire) alors que c'est justement son job de faire transiter des données potentiellement volumiques.
Grosse déception pour zstd, mon nouveau jouet préféré qui met généralement une patée à tous les autres algorithmes de compression dans la majorité des situations.
Après, peut-être que le cas du kernel n'est pas très représentatif de ce que j'ai rencontré dans la vie.
# tar
time tar -cf - linux-5.12-rc4/ | ssh remote 'tar -xf -'
real 2m7.831s
user 0m11.867s
sys 0m5.186s
# tar + gzip
time tar -czf - linux-5.12-rc4/ | ssh remote 'tar -xzf -'
real 1m49.364s
user 0m44.098s
sys 0m2.950s
# tar + zstd
time tar --zstd -cf - linux-5.12-rc4/ | ssh remote 'tar --zstd -xf -'
real 2m3.291s
user 0m10.835s
sys 0m3.075s
# scp
time scp -qr linux-5.12-rc4/ remote:~/
real 7m16.495s
user 0m25.576s
sys 0m33.962s
# scp compressé
time scp -qrC linux-5.12-rc4/ remote:~/
real 7m33.949s
user 1m43.966s
sys 0m28.784s
# rsync
time rsync -a linux-5.12-rc4/ remote:~/linux-5.12-rc4/
real 1m56.337s
user 0m18.617s
sys 0m5.389s
# rsync compressé
time rsync -az linux-5.12-rc4/ remote:~/linux-5.12-rc4/
real 1m56.317s
user 0m41.096s
sys 0m1.871s
Bref, tout ça pour dire que le pipe over SSH, dans plein de situations, c'est le bien. :)
[^] # Re: Pipe ?
Posté par George_abitbol . En réponse au journal Lancer un logiciel distant depuis sa machine. Évalué à 8.
En fait ça fonctionne avec n'importe quelle commande pipable.
C'est d'ailleurs quelque chose qui m'a sauvé des heures (et des points de santé mentale) dans le passé en transférant des fichiers via tar+ssh au lieu de scp. Aujourd'hui, avec le binaire rsync disponible de manière standard sur la plupart des serveurs, l'intérêt serait plus limité. Ça peut rester pertinent quand la source et la destination sont distantes par exemple.
J'allais écrire que c'est dû à la compression et que ça fonctionne bien notamment pour des données faiblement compressées et/ou les connexions lentes, mais finalement après avoir fait des tests, il se trouve que le fait de compresser ou pas n'a pas une incidence majeure. Mais utiliser tar+ssh ou rsync est infiniment plus efficace que scp.
ssh+tar+gz > rsync > rsync -z > ssh+tar+zstd > ssh+tar > scp > scp -C
Je ne m'explique pas pourquoi scp (même compressé) est à ce point si lent par rapport à la concurrence (bien pire que dans ma mémoire) alors que c'est justement son job de faire transiter des données potentiellement volumiques.
Grosse déception pour zstd, mon nouveau jouet préféré qui met généralement une patée à tous les autres algorithmes de compression dans la majorité des situations.
Après, peut-être que le cas du kernel n'est pas très représentatif de ce que j'ai rencontré dans la vie.
Bref, tout ça pour dire que le pipe over SSH, dans plein de situations, c'est le bien. :)