it-swarm.com.de

Wie kann die Leistung von FtpWebRequest verbessert werden?

Ich habe eine in .NET 3.5 geschriebene Anwendung, die FTP zum Hochladen/Herunterladen von Dateien von einem Server verwendet. Die App funktioniert gut, aber es gibt Leistungsprobleme:

  1. Das Herstellen einer Verbindung zum FTP-Server nimmt viel Zeit in Anspruch. Der FTP-Server befindet sich in einem anderen Netzwerk und verfügt über Windows 2003 Server (IIS FTP). Wenn mehrere Dateien zum Hochladen in die Warteschlange gestellt werden, wird durch den Wechsel von einer Datei zu einer anderen eine neue Verbindung mit FTPWebRequest hergestellt, was sehr viel Zeit in Anspruch nimmt (ca. 8-10 Sekunden).

  2. Kann ich die Verbindung wiederverwenden? Ich bin mir bezüglich der KeepAlive-Eigenschaft nicht ganz sicher. Welche Verbindungen bleiben erhalten und werden wiederverwendet?.

  3. Das IIS-FTP unter Windows Server 2003 unterstützt kein SSL, sodass jeder Benutzer den Benutzernamen/das Kennwort mithilfe eines Paket-Sniffers wie WireShark leicht erkennen kann. Ich fand heraus, dass Windows Server 2008 SSL über FTP in seiner neuen Version unterstützt, wenn IIS 7.0.

Grundsätzlich möchte ich die Upload-/Download-Leistung meiner Anwendung verbessern. Irgendwelche Ideen werden geschätzt.

** Bitte beachten Sie, dass 3 kein Problem ist, aber ich möchte, dass die Leute Kommentare dazu haben

34
A9S6

Ich habe mit FtpWebRequest einige Experimente (Hochladen von etwa 20 Dateien in verschiedenen Größen) mit den folgenden Faktoren durchgeführt

KeepAlive = wahr/falsch

ftpRequest.KeepAlive = isKeepAlive;

Verbindungsgruppenname = Benutzerdefiniert oder null

ftpRequest.ConnectionGroupName = "MyGroupName";

Verbindungslimit = 2 (Standard) oder 4 oder 8

ftpRequest.ServicePoint.ConnectionLimit = ConnectionLimit;

Modus = synchron oder asynchron 

siehe dieses Beispiel

Meine Ergebnisse:

  1. Verwenden Sie ConnectionGroupName, KeepAlive = true (21188.62 ms).

  2. Verwenden Sie ConnectionGroupName, KeepAlive = false (53449.00 ms).

  3. Kein ConnectionGroupName, KeepAlive = false nahm (40335,17 ms)

  4. Verwenden Sie ConnectionGroupName, KeepAlive = true; async = true, Verbindungen = 2 dauerte (11576,84 ms)

  5. Verwenden Sie ConnectionGroupName, KeepAlive = true; async = true, Verbindungen = 4 dauerte (10572,56 ms)

  6. Verwenden Sie ConnectionGroupName, KeepAlive = true; async = true, Verbindungen = 8 dauerte (10598,76 ms)

Schlussfolgerungen

  1. FtpWebRequestwurde entwickelt, um einen internen Verbindungspool zu unterstützen. Um sicherzustellen, dass der Verbindungspool verwendet wird, müssen wir sicherstellen, dass ConnectionGroupNamegesetzt wird. 

  2. Ein Verbindungsaufbau ist teuer. Wenn wir unter Verwendung der gleichen Anmeldeinformationen eine Verbindung zum selben FTP-Server herstellen, wird die Anzahl der Verbindungssetups minimiert, wenn das Keep Alive-Flag auf true gesetzt ist.

  3. Asynchron ist die empfohlene Methode, wenn Sie viele Dateien zu FTP haben.

  4. Die voreingestellte Anzahl von Verbindungen ist 2. In meiner Umgebung wird mir bei einem Verbindungslimit von 4 der größte Leistungsgewinn erzielt. Das Erhöhen der Anzahl von Verbindungen kann die Leistung verbessern oder nicht. Ich würde empfehlen, dass Sie die Verbindungsgrenze als Konfigurationsparameter verwenden, damit Sie diesen Parameter in Ihrer Umgebung anpassen können.

Ich hoffe, Sie finden das nützlich.

37
Syd

Es ist egal, ob die einzelnen Verbindungen lange brauchen, um eine Verbindung herzustellen, solange Sie mehrere Verbindungen gleichzeitig starten können. Wenn Sie viele Elemente (z. B. Hunderte) übertragen möchten, ist es sinnvoll, Dutzende oder sogar Hunderte von WebRequests parallel zu starten, und zwar mit den asynchronen Methoden wie BeginGetRequestStream und BeginGetResponse . Ich arbeitete an Projekten mit ähnlichen Problemen (lange Verbindungszeiten/Authentifizierungszeiten), aber durch die parallele Ausführung vieler Anrufe war der Gesamtdurchsatz tatsächlich sehr gut.

Es macht auch einen großen Unterschied, wenn Sie die asynchronen Methoden verwenden oder die synchrone Methode, sobald Sie viele (Dutzende, Hunderte) Anfragen haben. Dies gilt nicht nur für Ihre WebRequests-Methoden, sondern auch für Ihre Stream read / write - Methoden, die Sie nach dem Abrufen des Upload-/Download-Streams verwenden. Die Verbesserung der .Net-Leistung und Skalierbarkeit book ist etwas veraltet, aber ein Großteil seiner Ratschläge steht immer noch zur Verfügung und kann online gelesen werden.

Zu bedenken ist, dass die Klasse ServicePointManager im Framwework nur mit einem einzigen Ziel lauert: Ihre Leistung zu ruinieren. Stellen Sie sicher, dass Sie den ServicePoint Ihrer URL abrufen und ändern Sie ConnectionLimit auf einen angemessenen Wert (mindestens so viele, wie viele gleichzeitige Anforderungen Sie beabsichtigen).

18
Remus Rusanu

Debug-Netzwerk

Ein paar Tricks für einfaches Netzwerk-Debugging:

  1. Überprüfen Sie die Antwortzeiten, wenn Sie vom Anwendungsserver aus ein Ping an den FTP-Server senden.
  2. Überprüfen Sie die Antwortzeiten für eine Trace-Route (tracert von einer DOS-Shell).
  3. Übertragen Sie eine Datei mit dem Befehl ftp von der Befehlszeile.
  4. Stellen Sie über Telnet eine Verbindung zum FTP-Server her: telnet server 21.

Die Ergebnisse werden Hinweise zur Lösung des Problems liefern.

Netzwerkhardware

Für eine langsame Spurverfolgung:

  • Stellen Sie fest, warum die beiden Computer Probleme mit dem Netzwerk haben.
  • Aktualisieren Sie die Netzwerkhardware zwischen der langsamsten Verbindung.

Netzwerkkonfiguration

Für einen langsamen Ping:

  • Überprüfen Sie die Netzwerkkonfiguration auf jedem Computer.
  • Stellen Sie sicher, dass die Einstellungen optimal sind.

API überprüfen

In einer langsamen FTP-Sitzung in der Befehlszeile wird angezeigt, dass das Problem nicht von der verwendeten FTP-API getrennt ist. Es beseitigt die API nicht als potenzielles Problem, macht sie aber sicherlich weniger wahrscheinlich.

Netzwerkfehler

Wenn Pakete zwischen der Quelle und dem Ziel abgelegt werden, werden Sie von ping informiert. Möglicherweise müssen Sie die Paketgröße auf 1500 Byte erhöhen, um Fehler anzuzeigen.

FTP-Warteschlangenserver

Wenn Sie keine Kontrolle über den Ziel-FTP-Server haben, lassen Sie die hochgeladenen Dateien von einem zwischengeschalteten Server empfangen. Der Vermittler sendet dann die Dateien mit beliebiger Geschwindigkeit an den Remote-Server. Dies lässt den Eindruck entstehen, dass die Dateien schnell gesendet werden. Wenn die Dateien jedoch auf dem Remote-Server vorhanden sein müssen, sobald sie hochgeladen werden, ist diese Lösung möglicherweise nicht funktionsfähig.

FTP-Server-Software

Verwenden Sie einen anderen FTP-Daemon auf dem FTP-Server, z. B. ProFTPd als Windows-Dienst . (ProFTPd verfügt über Plug-Ins für verschiedene Datenbanken, die eine Authentifizierung mit SQL-Abfragen ermöglichen.)

FTP Server Betriebssystem

Ein Unix-basiertes Betriebssystem ist möglicherweise eine bessere Option als ein Microsoft-basiertes Betriebssystem.

FTP-Client-Software

Es gibt verschiedene APIs zum Senden und Empfangen von Dateien über FTP. Es kann einige Arbeit erfordern, um Ihre Anwendung so modular zu machen, dass Sie einfach einen neuen Dateiübertragungsdienst anschließen können. Einige verschiedene APIs sind hier als Antworten aufgeführt.

Alternatives Protokoll

Wenn FTP nicht unbedingt erforderlich ist, versuchen Sie Folgendes:

  • ein Windows-Netzlaufwerk
  • HTTPS
  • scp, rsync oder ähnliche Programme ( Cygwin möglicherweise erforderlich)
5
Dave Jarvis

Dieser Link beschreibt die Auswirkungen von ConnectionGroupName und KeepAlive: WebRequest ConnectionGroupName

4
Salar

Sie sollten auf jeden Fall BITS auschecken, was eine große Verbesserung gegenüber FTP darstellt. Die Klartext-Passwörter sind nicht die einzige Schwachstelle in FTP. Es gibt auch das Problem der Vorhersage des Ports, den er für einen passiven Upload oder Download öffnen wird, und die allgemeine Schwierigkeit, wenn Clients NAT oder Firewalls verwenden.

BITS funktioniert über HTTP/HTTPS mit den Erweiterungen IIS und unterstützt Uploads und Downloads in der Warteschlange, die mit niedriger Priorität geplant werden können. Insgesamt ist es wesentlich flexibler als FTP, wenn Sie Windows auf dem Client und dem Server verwenden.

BITS für PowerShell

BITS für .NET

3
Josh

Ich empfehle dringend, Starksoft FTP/FTPS-Komponente für .NET und Mono . Es hat ein Verbindungsobjekt, das Sie zwischenspeichern und wiederverwenden können.

2
Max Toro

Schauen Sie sich diese Seite an - http://www.ietf.org/rfc/rfc959.txt

Es besagt, dass beim Verbinden ein anderer Port verwendet werden muss, um die Verbindung wieder verwenden zu können.
Funktioniert es?

2
shahkalpesh

Ich persönlich habe alle unsere Apps von der FTP-Nutzung zum Hochladen/Herunterladen von Dateien entfernt und stattdessen eine auf XML-Webdiensten basierende Lösung in ASP.NET gerollt.

Die Leistung wurde erheblich verbessert, die Sicherheit ist so viel oder so wenig, wie Sie Code schreiben möchten (und Sie können das in .NET integrierte Material verwenden), und es kann alles ohne Probleme über SSL gehen. 

Unsere Erfolgsquote, die Verbindungen unserer Kunden über ihre eigenen Firewalls zu erhalten, ist weitaus besser als das Ausführen von FTP.

2
tomfanning

Ich würde empfehlen, auf rsync umzustellen.
Vorteile:
Optimiert für die Reduzierung der Übertragungszeit.
Unterstützt SSH für die sichere Übertragung
Verwendet TCP, wodurch Ihre IT-Abteilungs-/Firewall-Leute zufriedener werden 

Nachteile:
Keine native .NET-Unterstützung
Auf Linux-Server-Installationen ausgerichtet - obwohl es anständige Windows-Ports gibt, wie DeltaCopy

Insgesamt ist es jedoch eine viel bessere Wahl als FTP 

1
zebrabox

Um das Problem bezüglich der Leistung zu lösen, müssen Sie einfach Folgendes einstellen:

ftpRequest.ConnectionGroupName = "MyGroupName"; ftpRequest.KeepAlive = false; ftpRequest.ServicePoint.CloseConnectionGroup("MyGroupName");

1
paolo Giusti

Ich weiß, dass es ein alter Faden ist, aber ich musste kürzlich eine ähnliche Situation durchmachen.

Wir mussten 70+ XML-Dateien in weniger als 25 Minuten von einem FTP-Server herunterladen, ohne mehr als 5 Verbindungen in diesem Zeitraum zu öffnen.

Dies waren alle Alternativen, die wir ausprobiert haben:

  • wget - Es war schnell, aber jedes GET bedeutete eine neue Verbindung. Wir mussten aufhören, da viele Verbindungen hergestellt wurden. Wir hatten einige Probleme mit GETM, die im Web gut dokumentiert sind. Dies war keine Option.
  • FtpWebRequest - Jeder Aufruf von Create protokolliert eine neue Verbindung, obwohl wir die Eigenschaften KeepAlive und ConnectionGroupName verwendet haben. Außerdem war es sehr langsam.
  • Webclient - Wir haben nicht geprüft, ob eine neue Verbindung für jede Datei erstellt wurde (obwohl ich davon ausgehe, dass dies der Fall ist), aber es wurde 1 Datei/Minute kopiert. Es war also keine Option.

Am Ende haben wir altmodisches FTP-Batch-Skript verwendet. Es ist schnell und ich verwende nur eine Verbindung, um alle Dateien herunterzuladen. Es ist nicht flexibel, aber es ist viel schneller als alles andere, was ich ausprobiert habe (75 Dateien in weniger als 20 Minuten).

1
user2520528

Ich habe mit der FTP-Bibliothek von EDT gute Ergebnisse erzielt:

http://www.enterprisedt.com/products/edtftpnet/overview.html

1
Peter Recore

AFAIK, jedes FtpWebRequest muss eine neue Verbindung einrichten - einschließlich der Anmeldung am Server. Wenn Sie die FTP-Übertragungen beschleunigen möchten, würde ich empfehlen, stattdessen einen alternativen FTP-Client zu verwenden. Einige dieser alternativen Clients können sich anmelden und dann mehrere Aktionen mit derselben Befehlsverbindung ausführen.

Beispiele für solche Clients sind inklusiv: http://www.codeproject.com/KB/IP/FtpClient.aspx und enthält auch eine gute Erklärung, warum diese Bibliotheken schneller als die Standardfunktionen FtpWebRequest und http funktionieren können: //www.codeproject.com/KB/macros/ftp_class_library.aspx was auch nach einer einfachen Implementierung aussieht.

Ich persönlich habe meine eigene Implementierung von FTP in .NET 1.1 zurückgeworfen, bevor FtpWebRequest eingeführt wurde. Dies funktioniert immer noch gut für .NET 2.0.

0
Martin Robins

KeepAlive funktioniert. FtpWebRequest speichert die Verbindungen im Cache, sodass sie nach einiger Zeit wieder verwendet werden können. Einzelheiten und Erklärungen zu diesem Mechanismus finden Sie unter ServicePoint .

Eine weitere gute Informationsquelle ist der Blick auf die Quelle FtpWebRequest (Sie können dies auf VS2008 tun).

0
arbiter

Ich habe einige Benchmarks für FtpWebRequest durchgeführt, ähnlich der obigen Antwort von @Sid. Wenn KeepAlive auf true gesetzt wird, werden die asynchronen Aufrufe in meinem Test verbessert. Der Test besteht aus 

1) FtpWebRequest zum Überprüfen der Existenz von Dateien 2) FtpWebRequest zum Hochladen 3) FtpWebRequest zum Umbenennen einer Datei auf dem Server

Test FTP client 30 files of size 5 Kbytes took ... 14.897 seconds Test upload (alive true, connection name) 30 files of size 5 Kbytes took ... 34.229 seconds Test async(alive true, connection name) 30 files of size 5 Kbytes took ... 40.659 seconds Test send thread (alive true, connection name) 30 files of size 5 Kbytes took ... 38.926 seconds, 30 files

was sich verbessert hat, war die Implementierung eines FTP-Clients, der mit der Socket-Klasse erstellt wurde

der Benchmark ist hier

https://github.com/pedro-vicente/ftp_t

0
Pedro Vicente

ich habe ein paar Tage damit gearbeitet ... und die Geschwindigkeit war wirklich niedrig, nichts im Vergleich zu FileZilla ... endlich habe ich es mit Multithreads gelöst. 10 Threads, die Verbindungen zum Download herstellen, geben mir eine gute Quote, vielleicht könnten sie sogar noch weiter verbessert werden. Mit einer standardmäßigen ftprequest-Konfiguration

PeticionFTP.ConnectionGroupName = "MyGroupName"
PeticionFTP.ServicePoint.ConnectionLimit = 4
PeticionFTP.ServicePoint.CloseConnectionGroup("MyGroupName")

PeticionFTP.KeepAlive = False 
PeticionFTP.UsePassive = False

PeticionFTP.UseBinary = True

PeticionFTP.Credentials = New NetworkCredential(lHost.User, lHost.Password)
0
SpZ

Single Point of Beratung:

UNTERE BUFFER/CHUNK-GRÖSSEN VERMINDERN DIE LEISTUNG UMFASSEND

Grund: Viele weitere Festplatten-E/A, Speicher-E/A, FTP-Stream-Init und viele weitere Faktoren

0
Robin Rizvi