performante SCP/SFTP-Bibliothek gesucht

[musiKk]

Hi,

ein Java-Programm muss regelmäßig relativ große Datenmengen von einem Server laden. Das geschieht über SCP. Zur Zeit findet das über das Linux-Programm [c]scp[/c] statt, aber eine reine Java-Lösung wäre schöner.

Ich habe bisher drei Java-Implementierungen getestet: Trilead (gibts nicht mehr, aber wir haben noch die letzte freie Version), Jsch und sshtools (J2SSH). Das Problem dabei ist, dass die Downloadrate bei allen drei Implementierungen miserabel ist. Mit [c]scp[/c] erhalte ich etwa 1 bis 1.1MB/s - das Maximum, welches der Server liefert -, mit Trilead etwa 280k, mit Jsch 65k und mit sshtools bis etwa 150k. Bei keiner der Implementierungen kann ich hohe CPU-Auslastung feststellen, daher wundert es mich sehr, wieso die Downloadraten so schlecht sind.

Vielleicht kennt jemand eine bessere Implementierung, die auch hohe Datenraten liefert.

Danke schonmal
mK

 

[ARadauer]

ich mach das immer mit ant
SCP Task

asso... wird dir nix helfen die verwenden auch jsch.. mhn aber du kannst es ja mal ausprobieren, ob das schneller geht

 

[FArt]

Hm, so Blackbox-Diagnosen sind immer ein wenig heikel.
Wie ist denn der Test aufgebaut (eine große Datei? viele kleine Dateien?), wie sieht zum Vergleich der scp Befehl aus und wie verwendest du die API? Es wäre schon interessant zu wissen, wo denn die Performance verloren geht...

[EDIT]
Ok, schon was gefunden... SourceForge.net: SSHTools: Detail: 1734970 - Need changes for better performance of large file upload

 

[musiKk]

Ja, es ist schon klar, dass ein pauschales "alles lahm" nicht viel bringt.

Ich muss relativ große Dateien übertragen. Im Schnitt mehrere hundert MB, daher ist der Unterschied 200k - 1MB auch sehr relevant. Der Test ist so einfach wie möglich aufgebaut. Ich verbinde mich und rufe das jeweilige Äquivalent einer [c]getFile()[/c]-Methode auf. Oft erhält man dabei einen [c]InputStream[/c], da habe ich z. B. mit verschiedenen Buffer-Größen experimentiert (1-16k) - ohne Erfolg. Manchmal kann man die lokale Speicherung der Bibliothek überlassen, da waren die Ergebnisse auch immer gleich.

Ich werde mir bzgl. sshtools mal anschauen, was der verlinkte Patch macht. Aktuell ist halt Version 0.2.9 und der Patch ist für 0.2.7, von daher muss ich sehen, was das bringt.

Dennoch wundere ich mich einfach, wieso die Performance aller von mir getesteten Implementierungen so grottig ist. Wenn irgendwelche Entschlüsselungsroutinen schlecht geschrieben wären und die ganze CPU beanspruchen würden... aber ich kann gar nichts erkennen. Einen Fehler meinerseits würde ich natürlich nicht ausschließen, aber gerade wegen weiterer Fehlerquellen habe ich die Tests sehr einfach gehalten. Ich kann ja spaßeshalber mal ein Beispiel für sshtools zeigen:

SshClient sshClient = new SshClient();
sshClient.connect(host, port);

PasswordAuthenticationClient auth = new PasswordAuthenticationClient();
auth.setUsername(user);
auth.setPassword(pass);
sshClient.authenticate(auth);

ScpClient scpClient = sshClient.openScpClient();
scpClient.get("/tmp/flurbs", "remote/file", false);

sshClient.disconnect();

im Vergleich zu [c]scp -P port user@host:remote/file /tmp/flubs[/c]. Nichts besonderes also. Gerade der [c]ScpClient[/c] hat neben [c]get()[/c] und [c]put()[/c] keine weiteren Methoden. Bei den anderen sieht es ähnlich aus.

Was mir noch einfällt... vielleicht hat das sogar noch ganz andere Gründe. Intern geht die Übertragung auch mit den Java-Implementierungen sehr schnell. Nur bei dem bestimmten Server, von dem die Daten geholt werden müssen, tritt das Problem auf. D. h. die Java-Implementierungen machen da noch irgendwas anders als das Kommandozeilentool. Ich erwähns nur nebenbei, aus der Ferne kann man das sicher nicht diagnostizieren. Ich habe da leider gar keinen Ansatz...

 

[HoaX]

Evtl wird eine andere Verschlüsselung verwendet? Dass könnte die Unterschiede erklären.

 

[Grizzly]

@musiKk: Hat sich bzgl. des Themas eigentlich noch irgendwas ergeben?

 

[musiKk]

@musiKk: Hat sich bzgl. des Themas eigentlich noch irgendwas ergeben?

Leider nicht; ich hatte die reine [c]scp[/c]-Variante beibehalten.

 

[Grizzly]

Leider nicht; ich hatte die reine [c]scp[/c]-Variante beibehalten.

Okay, trotzdem Danke für die Info.