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.
Je n'ai pas vraiment ressenti cette lenteur, mais SCp et SSh ne fonctionnent absolument pas de la même façon... Je ne me rappelle pas bien les détails d'implémentation, mais quand tu fais un tube avec SSh, tu ouvres un pseudo-terminal dont tu connectes l'entrée standard (donc tu envois ton flux exactement comme tu le balancerais si tu le tapais au clavier...) Par contre quand tu fais un SCp, en dessous tu établies un liaison client-serveur (si, si, et toutes les bécanes ayant un serveur ssh ne permettent pas d'accepter du scp —comme c'est paquetagé dans OpenSSH utilisé par défaut dans beaucoup d'Unix, des BSD à Linux en passant par AIX— bah on s'en rend pas compte) comparable à curl/lftp -c/ftpget/ftpput (c'est encore différent du sous-système sftp qui ressemble plus à du ftp classique et utilise un tout autre protocole) Ça fait un certain nombre d'opérations (vérifier et se positionner dans le répertoire cible, vraiment recréer les arborescence quand utilisé en mode récursif, afficher la progression, etc.)
tar -czf - linux-5.12-rc4/ | ssh remote 'tar -xzf -'
cet exemple est en fait comparable à ceci :
# il faut helas preparer le fichier avant car scp ne lit pas stdin
tar -czf foo.tgz linux-5.12-rc4/
# puis l'envoyer separement
scp foo.tgz remote:./ ; rm foo.tgz
# et en face l'extraire car il n'exploite pas stdout
tar -xzf foo.tgz ; rm foo.tgz
et là on voit que la plus grande rapidité apparente, en supposant qu'on ait eu les même protocoles et que les deux outils ne se partagent pas que le mode de transport, est due au fait que dans le premier cas on parallélise presque (la gestion des tubes fait qu'on n'attend pas que tout se fasse séquentiellement)
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: Pipe ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au journal Lancer un logiciel distant depuis sa machine. Évalué à 5.
Je n'ai pas vraiment ressenti cette lenteur, mais SCp et SSh ne fonctionnent absolument pas de la même façon... Je ne me rappelle pas bien les détails d'implémentation, mais quand tu fais un tube avec SSh, tu ouvres un pseudo-terminal dont tu connectes l'entrée standard (donc tu envois ton flux exactement comme tu le balancerais si tu le tapais au clavier...) Par contre quand tu fais un SCp, en dessous tu établies un liaison client-serveur (si, si, et toutes les bécanes ayant un serveur
sshne permettent pas d'accepter duscp—comme c'est paquetagé dans OpenSSH utilisé par défaut dans beaucoup d'Unix, des BSD à Linux en passant par AIX— bah on s'en rend pas compte) comparable àcurl/lftp -c/ftpget/ftpput(c'est encore différent du sous-systèmesftpqui ressemble plus à duftpclassique et utilise un tout autre protocole) Ça fait un certain nombre d'opérations (vérifier et se positionner dans le répertoire cible, vraiment recréer les arborescence quand utilisé en mode récursif, afficher la progression, etc.)cet exemple est en fait comparable à ceci :
et là on voit que la plus grande rapidité apparente, en supposant qu'on ait eu les même protocoles et que les deux outils ne se partagent pas que le mode de transport, est due au fait que dans le premier cas on parallélise presque (la gestion des tubes fait qu'on n'attend pas que tout se fasse séquentiellement)
"It is seldom that liberty of any kind is lost all at once." ― David Hume