Les vitesses de téléchargement SCP semblent être considérablement limitées dans la bibliothèque par rapport aux capacités de l'utilitaire scp de ligne de commande. Je comprends que c'est Ruby (1.9.2-p0), mais Net :: SCP est environ 8 fois plus lent que l'utilitaire Linux (vu en utilisant de gros fichiers ... voir ci-dessous). Je suis curieux de savoir (j'ai jeté un coup d'oeil au code) si c'est comme ça que les sockets sont en Ruby, ou s'il est possible de multiplexer les sockets Net :: SCP mieux? J'ai remarqué que peu importe le style de téléchargement que j'ai essayé (téléchargement en série, canaux fonctionnant de manière asynchrone, utilisation de plusieurs instances de l'objet scp), je ne pouvais jamais obtenir plus de 9 mégaoctets/seconde de transfert sur un téléchargement SCP. Maintenant ... laissez-moi vous expliquer les détails de mon enquête:Problèmes de performances avec les transferts Ruby et Net :: SCP (sockets)
1) Essayé différents algorithmes de chiffrement
j'ai utilisé différents types de cryptage sans beaucoup de changement de vitesse significative Exemple: Je pourrais soumettre mon dossier de test de 1 Go en utilisant ligne de commande scp (algorithme de chiffrement = arcfour128) et obtenir un taux de transfert de 73,3 mégaoctets/s sur ma connexion interne gigabit. Je n'ai jamais eu plus de 9 mégaoctets/s sur ma connexion interne gigabit en utilisant la librairie Net :: SCP.upload.
2) Essayé différents hôtes/systèmes d'exploitation
Je trouve que Linux -> Linux téléchargements étaient les plus rapides. Le serveur ssh de SUA (Windows) ne pouvait me fournir que 13,5 mégaoctets/s de vitesse de téléchargement (Linux -> Windows, en utilisant l'algorithme arcfour w/scp), alors que Linux -> Linux (en utilisant arcfour, w/scp ligne de commande) était un flamboyant 73.3megabytes/s. Je dois mentionner que ces machines de Windows et Linux sont exactement le même modèle, le matériel, etc.
3) Différentes méthodes de Essayé téléchargement SCP
-> utilisé 2 téléchargement synchrone! appels, l'un après l'autre était terminé. -> utilisé 2 appels de téléchargement asynchrones, l'un après l'autre avait commencé -> utilisé 2 Net :: SCP objets et soumis le fichier à la version non bloquante/asynchrone de téléchargement (de sorte qu'ils étaient en cours d'exécution en parallèle) Aucune de ces différentes méthodes donner un gain de performance significatif, ce qui est plutôt frustrant.
Voici les résultats du test (texte amélioré pour une meilleure lisibilité, mais similaire à la sortie du code fourni):
Net::SCP
Done creating channels
Starting transfer of /home/seth/afpcases/systeme.afp # two upload! calls, one after another
Finished transfer of /home/seth/afpcases/systeme.afp
--> Duration: 126.07707 seconds (8.7168903909331 megabytes/s) should show transfer speed of serial uploads
Starting transfer of /home/seth/afpcases/systeme.afp # two upload calls, one after another, with a wait on both channels after both have started
Finished transfer of /home/seth/afpcases/systeme.afp
--> Duration: 122.588784 seconds (8.964931082112699 megabytes/s) should show transfer speed of simultaneous async channels.
Starting transfer of /home/seth/afpcases/systeme.afp # two upload calls on two separate Net::SCP objects, one after another, with a wait on both channels after both have started
Finished transfer of /home/seth/afpcases/systeme.afp
--> Duration: 122.822663 seconds (8.947860054133495 megabytes/s) should show transfer speed of simultaneous SCP instances
Finished in 371.761262 seconds
Si vous avez un gros fichier (j'ai utilisé un fichier ~ 1 Go), vous pouvez utiliser ces tests rspec (dans scp_spec.rb) ou les changer pour les harnais de test que vous connaissez pour voir cette dégradation des performances. Si vous ne savez pas comment cette performance pourrait être améliorée dans la bibliothèque, avez-vous d'autres idées sur la façon d'ouvrir une vitesse parallèle supplémentaire de transferts SCP en plus d'appeler simplement l'utilitaire scp via un sous-shell?
essai Rspec ici: https://gist.github.com/703966