web-dev-qa-db-fra.com

Quel est le moyen le plus rapide pour transférer des fichiers sur un réseau (FTP, HTTP, RSync, etc.)

J'essaie de trouver la meilleure façon de transférer de grandes quantités de données sur un réseau entre deux systèmes. Je regarde actuellement FTP, HTTP ou RSync, et je me demande lequel est le plus rapide. J'ai cherché en ligne des réponses et trouvé les sites suivants:

Le problème est qu'ils sont anciens et parlent davantage des différences théoriques entre la façon dont les protocoles communiquent. Je suis plus intéressé par les benchmarks réels, cela peut dire que pour une configuration spécifique, lors du transfert de fichiers de tailles différentes, un protocole est x% plus rapide que les autres.

Quelqu'un a-t-il testé ces informations et publié les résultats quelque part?

httpnetworkingfile-uploadftprsync
21
oneself

D'accord, j'ai donc configuré le test suivant:

  • Matériel: 2 ordinateurs de bureau Intel Core Duo à 2,33 GHz, avec 4 Go de RAM.
  • OS: Ubuntu 11.10 sur les deux machines
  • Réseau: commutateur dédié de 100 Mo, les deux machines y sont connectées.
  • Logiciel:

J'ai téléchargé les groupes de fichiers suivants sur chaque serveur:

  1. 1 fichier de 100M.
  2. 10 fichiers 10M.
  3. 100 fichiers 1M.
  4. 1000 fichiers 100K.
  5. 10000 fichiers 10K.

J'ai obtenu les résultats moyens suivants sur plusieurs exécutions (nombres en secondes):

|-----------+---------+----------|
| File Size | FTP (s) | HTTP (s) |
|-----------+---------+----------|
|      100M |       8 |        9 |
|       10M |       8 |        9 |
|        1M |       8 |        9 |
|      100K |      14 |       12 |
|       10K |      46 |       41 |
|-----------+---------+----------|

Il semble donc que FTP soit légèrement plus rapide dans les gros fichiers et HTTP dans les nombreux petits fichiers. Dans l'ensemble, je pense qu'ils sont comparables, et la mise en œuvre du serveur est beaucoup plus importante que le protocole.

35
oneself

Si les machines à chaque extrémité sont raisonnablement puissantes (c.-à-d. Pas les netbooks, NAS, grille-pain, etc.), alors je m'attendrais à tous les protocoles qui fonctionnent sur TCP pour être à peu près la même vitesse de transfert de données en masse. Le travail du protocole d'application est vraiment juste de remplir un tampon pour TCP à transférer, donc tant qu'ils peuvent le garder plein, TCP fixera le rythme.

Les protocoles qui effectuent la compression ou le chiffrement peuvent goulot d'étranglement au niveau du processeur sur les machines moins puissantes. Mon netbook fait FTP beaucoup plus rapidement que SCP.

rsync fait des choses intelligentes pour transmettre rapidement les modifications incrémentielles, mais pour les transferts en masse, il n'a aucun avantage sur les protocoles plus stupides.

7
Tom Anderson

Un autre utilitaire à considérer est bbcp: http://www.slac.stanford.edu/~abh/bbcp/ .

Un bon tutoriel, mais daté, pour l'utiliser est ici: http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm . J'ai trouvé que bbcp est extrêmement efficace pour transférer des fichiers volumineux (plusieurs Go). D'après mon expérience, il est plus rapide que rsync en moyenne.

4
kadal

rsync compresse éventuellement ses données. Cela accélère généralement le transfert. Voir rsync -z .

Vous n'avez pas mentionné scp, mais scp -C compresse également.

Notez que la compression peut accélérer le transfert ou plus lentement, en fonction de la vitesse de votre CPU et de votre lien réseau. (Des liens plus lents et un processeur plus rapide font de la compression une bonne idée; des liens plus rapides et un processeur plus lent font de la compression une mauvaise idée.) Comme pour toute optimisation, mesurez les résultats dans votre propre environnement.

3
Robᵩ

Je crains que si vous voulez connaître la réponse à vos besoins et à votre configuration, vous devez soit être plus précis ou faire vos propres tests de performances (et de fiabilité). Cela aide à avoir une compréhension au moins rudimentaire des protocoles en question et de leur communication, donc je considérerais les articles que vous avez cités comme une ressource utile. Cela permet également de savoir à quelles restrictions les premiers inventeurs de ces protocoles étaient confrontés - leur objectif était-il de maintenir un faible impact sur le réseau, étaient-ils affamés de mémoire ou devaient-ils compter leurs cycles de processeur? Voici quelques éléments à considérer ou à répondre si vous souhaitez obtenir une réponse adaptée à votre situation:

  • Concernant le système d'exploitation/fichier:
    • copiez-vous entre la même combinaison OS/FS ou devez-vous vous soucier des incompatibilités, telles que les types de fichiers sans correspondance équivalente à la réception?
    • C'est à dire. avez-vous quelque chose de spécial à transporter? Les métadonnées, les fourchettes de ressources, les attributs étendus, les autorisations de fichiers peuvent soit ne pas être transportées par le protocole/l'outil de votre choix, soit être dénuées de sens à la réception.
    • Il en va de même pour les fichiers clairsemés, qui pourraient finir par être gonflés à leur pleine taille à l'autre extrémité de la copie, ruinant tous les plans que vous avez pu avoir sur le dimensionnement.
  • Contraintes physiques liées:
    • Impact sur le réseau
    • charge CPU: de nos jours, la compression est beaucoup "moins chère", car les processeurs modernes sont moins mis à l'épreuve par la compression que ceux de l'époque où la plupart des protocoles de transfert étaient conçus.
    • tolérance aux défaillances - devez-vous pouvoir reprendre là où un transfert interrompu vous a laissé, ou préférez-vous recommencer?
    • transferts incrémentiels ou transferts complets? Un transfert incrémentiel représente-t-il de grandes économies pour vous, ou avez-vous quand même des transferts complets par conception de votre tâche? Dans ce dernier cas, la latence supplémentaire et l'impact sur la mémoire pour construire la liste de transfert avant de commencer le transfert seraient un compromis moins souhaitable.
    • Quelle est la qualité du protocole d'utilisation du MTU disponible par votre protocole réseau sous-jacent?
    • Avez-vous besoin de maintenir un flux constant de données, par exemple pour garder un lecteur de bande en streaming à l'extrémité de réception?

Beaucoup de choses à considérer, et je suis sûr que la liste n'est même pas complète.

2
Tatjana Heuser