FTPS-Leistung mit kleinen XML-Dateien bei sehr hohem Volumen

447
Donz

Unser Unternehmen baut eine b2b-Integration mit einer anderen Partei auf, die von ihnen verlangt, uns eine große Anzahl von ~ 100.000 XML-Dateien mit jeweils etwa 10-15 KB im Verlauf eines dreistündigen Zeitfensters zu liefern . Wir planen, für diesen Austausch unseren hochverfügbaren FTPS-Server (TLS / SSL) zu verwenden, der unter Linux ausgeführt wird.

Die andere Partei hat Bedenken hinsichtlich der Lese- / Schreib-Overheads von FTPS geäußert und erklärt, dass die Übertragung wahrscheinlich über das zulässige Fenster hinausgeht. Unsere Infrastrukturspezialisten versichern mir, dass diese Anzahl von Dateien über FTPS, insbesondere auf einem HA-Linux-Server, kein Problem darstellt, solange wir sie nach dem Abholen der Datei löschen.

Ich möchte den oben genannten Ansatz begründen. Hat jemand eine Übertragung mit hohem Volumen über FTPS implementiert? Ist das eine schlechte Idee und sollten wir einen warteschlangenbasierten Ansatz implementieren?

Es ist zu spät, um Probleme während unseres Belastungstests zu entdecken. Entschuldigung, wenn die Frage etwas offen ist. Wenn Sie bestimmte Details benötigen, kann ich Ihnen das gerne mitteilen. Vielen Dank

1
Das sind also durchschnittlich 10 Transfers pro Sekunde (Spitzen und Täler sind zu erwarten?) ... mit FTPS und das über einem WAN? Wie ist die Latenz? Und sind diese Übertragungen aufeinanderfolgend oder wird es Parallelen geben? misha256 vor 9 Jahren 0

2 Antworten auf die Frage

1
davidgo

Kurze Antwort: Wenn sich die Server nahe beieinander befinden, können Sie dies möglicherweise tun, wenn sie weit weg sind, werden Sie wahrscheinlich das Übertragungsfenster sprengen. In jedem Fall ist es jedoch eine schlechte Idee für die "einfache" Implementierung.

Die ausführlichere Antwort:

Ich denke nicht, dass diese Seite für die Art von Frage geeignet ist - die richtige Antwort lautet "es kommt darauf an" und "Sie sollten Ihre eigenen Tests durchführen". (Auch Serverfault wäre vielleicht ein besseres Forum, da dieses Forum eher für Hobbys ist).

Das heißt, ich frage FTPS als eine gute Lösung, da es einen sehr hohen Overhead zu haben scheint - FTP ist schlecht genug, bevor der zusätzliche Overhead für die Verschlüsselung hinzugefügt wird.

Ob dies technisch machbar ist, hängt maßgeblich von der Geschwindigkeit Ihrer Pipe, der Entfernung zwischen den Servern und der Anzahl der gleichzeitigen Verbindungen ab, die Sie herstellen [mehrere Verbindungen können eine hohe Latenz bis zu einem gewissen Grad verringern.]

Wenn Sie mehrere Dateien in einer größeren Datei zusammenführen können, übertragen Sie sie und dekomprimieren Sie sie. Dadurch werden erhebliche Leistungssteigerungen erzielt, weil:

  1. Sie reduzieren die Probleme mit der Latenz (und dem Rechenaufwand für die Verschlüsselung, aber lassen Sie diese ignorieren, da sie relativ zum Rest des Problems nicht wesentlich sind).
  2. Sie komprimieren die Dateien und reduzieren die Datenmenge, die übertragen werden muss.

Sie haben nicht angegeben, wie die Übertragungen funktionieren würden - wäre dies eine einzige FTPS-Sitzung, bei der mehrere Dateien hochgeladen werden, oder eine separate FTP-Sitzung für jede Datei.

Die letztere Lösung - die vermutlich einfacher zu programmieren ist - würde vermutlich einen RIESIGEN Overhead verursachen, da jede einzelne Verbindung ausgehandelt werden müsste und diese Verhandlung relativ zu einer kleinen Datei teuer ist. (Ich bin kein Experte für FTPS, aber TLS fügt normalerweise jeder Anfrage etwa 6-7k Overhead hinzu und FTPS ist eine FTP-Sitzung, die in einem TLS-Ine eingeschlossen ist.)

Die Latenzzeit pro Anforderung würde unter der Annahme, dass die Nutzlast unwichtig war, um das Dreifache steigen. Dies ist möglicherweise nicht wichtig, wenn sich die Sites im selben Netzwerk befinden, aber wenn Sie beispielsweise eine Seite der Verbindung in New York und die andere in LA 80ms hatten, werden Sie erhebliche Latenzprobleme feststellen, wenn Sie dies mit der Anzahl von multiplizieren Dateien, und Sie werden wahrscheinlich Ihr Übertragungsfenster durchbrennen - selbst wenn der NAS damit umgehen kann.

Schöne Zusammenfassung. Ich bin zuversichtlich, dass die Zahlen für sich sprechen. 10 Transaktionen pro Sekunde sind einfach nicht machbar, Sie hätten nur 100 ms pro Datei. Die Ping-Zeit alleine kann mehr als die eines WAN sein. Es sei denn, es wurden mehrere Verbindungen verwendet, aber selbst dann scheint es fragwürdig. misha256 vor 9 Jahren 0
1
misha256

Ich werde hier eine Antwort geben, die das Problem quantifiziert, mit dem Sie wahrscheinlich konfrontiert sind. Ich habe auch die Antwort von davidgo gewählt, weil sie das Problem richtig beschreibt.

Bedenken Sie, dass 100.000 Transfers über drei Stunden einem Durchschnitt von etwa 10 Transfers pro Sekunde entsprechen . Das sind 100 Millisekunden pro Übertragung.

Die Server-zu-Server-Latenzzeit müsste um eine Größenordnung geringer sein, etwa 10 ms, damit die Hoffnung besteht, mit der Übertragungsrate Schritt zu halten.

Wenn die Server über WAN verbunden sind, können Sie dies für unmöglich halten. Es sei denn, Sie nehmen mehrere gleichzeitige Verbindungen in Anspruch, aber wenn die Transaktionen selbst aufeinander folgen, werden potenzielle Gewinne, die Parallelität bieten, effektiv ausgeschlossen.

Verwandte Probleme