Comment améliorer les performances de FtpWebRequest?

Question

J'ai une demande écrite .NET 3.5, qui utilise FTP pour charger/télécharger des fichiers à partir d'un serveur. L'application fonctionne très bien mais il y a des problèmes de performances:

1. Il faut beaucoup de temps pour établir la connexion au serveur FTP. Le serveur FTP est sur un autre réseau et Windows 2003 Server (IIS FTP). Lorsque plusieurs fichiers sont mis en file d'attente pour l'envoi, la modification d'un fichier à l'autre crée une nouvelle connexion à l'aide FTPWebRequest et il prend beaucoup de temps (environ 8 à 10 secondes).

2. Il est possible de ré-utiliser la connexion? Je ne suis pas très sûr de la propriété Persistante. Les connexions sont conservées et réutilisées.

3. L'IIS FTP sur Windows Server 2003 ne prend pas en charge SSL donc n'importe qui peut facilement voir le nom d'utilisateur/mot de passe par le biais d'un renifleur de paquets tel que WireShark. J'ai trouvé que windows Server 2008 prend en charge SSL via FTP dans sa nouvelle version si IIS 7.0.

En gros, je veux améliorer la charger/télécharger des performances de mon application. Toutes les idées seront appréciées.

** Veuillez noter que 3 n'est pas un problème, mais j'aimerais que les gens ont des commentaires sur l'

Answer 1

J'ai fait quelques essais (téléchargement d'environ 20 fichiers sur différentes tailles) sur FtpWebRequest avec les facteurs suivants

KeepAlive = true/false

ftpRequest.KeepAlive = isKeepAlive;

Connexion Nom du Groupe = défini par l'utilisateur ou null

ftpRequest.ConnectionGroupName = "MyGroupName";

Limite de connexion = 2 (valeur par défaut) ou 4 ou 8

ftpRequest.ServicePoint.ConnectionLimit = ConnectionLimit;

Mode = Synchrone ou Asynchrone

voir cet exemple

Mes résultats:

1. Utilisation ConnectionGroupName,KeepAlive=true pris (21188.62 msec)

2. Utilisation ConnectionGroupName,KeepAlive=false pris (53449.00 msec)

3. Pas de ConnectionGroupName,KeepAlive=false pris (40335.17 msec)

4. Utilisation ConnectionGroupName,KeepAlive=true;async=true,les connexions=2 a (11576.84 msec)

5. Utilisation ConnectionGroupName,KeepAlive=true;async=true,les connexions=4 a (10572.56 msec)

6. Utilisation ConnectionGroupName,KeepAlive=true;async=true,les connexions=8 a (10598.76 msec)

Conclusions

1. FtpWebRequest a été conçu pour une connexion interne de la piscine. Pour s'assurer, le pool de connexion est utilisé, il faut s'assurer que l' ConnectionGroupName est en cours de mise.

2. L'établissement d'une connexion est cher. Si nous sommes de se connecter au même serveur ftp en utilisant les mêmes informations d'identification, d'avoir la garder vivante indicateur a la valeur true permet de réduire le nombre de connexions de l'installation.

3. Asynchrone est la méthode recommandée si vous avez beaucoup de fichiers en ftp.

4. La valeur par défaut du nombre de connexions est de 2. Dans mon environnement, une limite de connexion de 4 va me donner le plus global de gain de performance. Augmenter le nombre de connexions peuvent ou ne peuvent pas améliorer la performance. Je recommanderais que vous avez la connexion de la limite d'un paramètre de configuration de sorte que vous pouvez régler ce paramètre dans votre environnement.

Espérons que vous trouverez ce utile.

Answer 2

Il n'a pas d'importance si la personne connexions prendre longtemps pour se connecter tant que vous pouvez lancer plusieurs en parallèle. Si vous avez beaucoup d'éléments à transférer (des centaines), alors il est logique de lancer des dizaines et même des centaines de WebRequests en parallèle, en utilisant les méthodes asynchrones comme BeginGetRequestStream et BeginGetResponse. J'ai travaillé sur des projets qui sont confrontés à des problèmes similaires (long connecter/s'authentifier fois) mais par l'émission de nombreux appels en parallèle le débit global était vraiment très bon.

Aussi, il fait une énorme différence si vous utilisez les méthodes asynchrones ou synchrones à un, dès que vous avez plusieurs (dizaines, centaines) de demandes. Cela s'applique non seulement à votre WebRequests méthodes, mais aussi à votre Flux de lire/écrire les méthodes que vous allez utiliser après l'obtention de l'upload/download stream. L'Amélioration De L' .Net les Performances et l'Évolutivité du livre est un peu dépassé, mais beaucoup de ses conseils toujours debout, et est libre de lire en ligne.

Une chose à considérer est que le ServicePointManager classe se trouve là, tapi dans l'Framwework avec un seul but: pour ruiner votre performance. Assurez-vous d' obtenir l'ServicePoint de votre URL et modifier le ConnectionLimit à une valeur raisonnable (au moins aussi élevé que le nombre de demandes simultanées que vous avez l'intention).

Answer 3

Débogage Réseau

Quelques trucs pour la simple réseau de débogage:

1. Vérifier les temps de réponse lorsque vous vous connectez au serveur FTP depuis le serveur d'application.
2. Vérifier les temps de réponse pour un trace route (tracert à partir d'un shell DOS).
3. Le transfert d'un fichier à partir de la ligne de commande à l'aide de l' ftp commande.
4. Se connecter au serveur FTP via Telnet: telnet server 21.

Les résultats fournissent des indices pour résoudre le problème.

Matériel Réseau

Une lente itinéraire suivi:

• Déterminer pourquoi les deux ordinateurs ayant des problèmes de réseau.
• Mettre à niveau le matériel de réseau entre le lien plus lent.

La Configuration Du Réseau

Une lente ping:

• Vérifiez la configuration du réseau sur chaque machine.
• S'assurer que les paramètres sont optimales.

Valider API

Un slow de ligne de commande de session FTP vous dire que le problème n'est pas isolé sur le FTP API que vous utilisez. Il n'élimine pas l'API, comme un problème potentiel, mais certainement le rend moins probable.

Des Erreurs De Réseau

Si les paquets sont abandonnés entre la source et la destination, ping vais vous le dire. Vous pourriez avoir à augmenter la taille des paquets de 1500 octets pour voir toutes les erreurs.

FTP Serveur de File d'attente

Si vous n'avez aucun contrôle sur la destination FTP serveur, un serveur intermédiaire recevoir des fichiers téléchargés. L'intermédiaire alors envoie les fichiers sur le serveur distant, à la vitesse qu'il peut. Cela donne l'illusion que les fichiers sont envoyés rapidement. Toutefois, si les fichiers doivent exister sur le serveur distant dès qu'ils sont téléchargés, puis cette solution pourrait ne pas être viable.

Le Logiciel Serveur FTP

Utiliser un autre démon FTP sur le serveur FTP, comme ProFTPd en tant que service Windows. (ProFTPd a des plugins pour diverses bases de données qui permettent l'authentification à l'aide de requêtes SQL.)

FTP Serveur de Système d'Exploitation

Un Unix système d'exploitation peut être une meilleure option qu'un Microsoft un.

Logiciel de Client FTP

Il y a un certain nombre de différentes Api pour l'envoi et la réception de fichiers via FTP. Il pourrait prendre un certain travail à faire votre demande suffisamment modulaire qui vous permet de brancher simplement un nouveau service de transfert de fichiers. Quelques Api différentes sont répertoriées comme des réponses ici.

Autre Protocole

Si FTP n'est pas une exigence absolue, essayez:

• un lecteur réseau Windows
• HTTPS
• scp, rsync, ou des programmes similaires (Cygwin peut être nécessaire)

Answer 4

Ce lien décrit ConnectionGroupName et KeepAlive affecte: WebRequest ConnectionGroupName

Answer 5

Vous devriez certainement vérifier les BITS qui est une grande amélioration sur le FTP. Le texte en clair les mots de passe ne sont pas la seule faiblesse de FTP. Il y a également le problème de la prédiction du port, elle va ouvrir un passif de chargement ou de téléchargement et de façon générale, la difficulté lorsque les clients sont à l'aide de NAT ou de pare-feu.

BITS fonctionne sur HTTP/HTTPS à l'aide de IIS extensions et prend en charge en file d'attente des téléchargements et des téléchargements qui peut être planifiée à faible priorité. C'est globalement beaucoup plus souple que le FTP si vous utilisez Windows sur le client et le serveur.

BITS pour PowerShell

BITS pour .NET