Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting] Montag, 14 Januar 2008 | Blog: 5 | No: 10901
Ich habe gerade mal einen SMB Client Modus in "dl" gehackt, das kleine Toolchen, das bei gatling dabei liegt. Der SMB-Modus in gatling ist immer noch richtig doll schlecht, gerade ausreichend, um in mplayer/mencoder per smbclient eine smb://notebook/pub/dateiname URL lesend zu benutzen (dafür war es auch gedacht). Aber was soll ich euch sagen, wenn man sowas schon mal hat, dann kann man ja auch mal gucken. dl ist richtig doll stupide und kann halt jetzt auch neben http:// und ftp:// smb://, aber das reicht schon für folgende Überraschung: große ISO-Datei ziehen, über Gigabit Ethernet, zwischen Desktop (samba) und Notebook (dl):
Das ist einfach so lahm, weil SMB die Dateien immer blockweise verschickt. D.h. man schickt einen Request, dass man 60k Datei ab Offset 0 haben will, dann liest man eine Antwort mit den Daten, dann schickt man den nächsten Request. Die Pipeline zwischen Server und Client bleibt immer stehen, wenn der gerade einen Request rausgeschickt hat, bis der nächste Request kommt. Da kommt dann mehrfach die Round Trip Zeit dazu, die Ethernet hat (das ist im Millisekundenbereich, aber das läppert sich).
Gut, aus dieser Erkentnis müsste man ja Kapital schlagen können. Also habe ich mal dl aufgehackt, damit er den nächsten Read Request immer schon rausschickt, wenn er gerade anfängt, die Antwort auf den letzten zu lesen. Hier gegen Samba:
Die 92 MB/sec sind schon recht nah an HTTP dran. Mit HTTP kriege ich im selben Szenario 97 MB/sec. Das ist, falls sich jemand fragt, deshalb nicht wire speed, weildas über TCP geht, und TCP am Anfang eine Weile braucht, bis die Window Size groß genug ist. Bei einem Transfer, der insgesamt nur 10 Sekunden braucht, schlägt sich das dann so nieder. meine Zeitmessungen nur mit Sekundenauflösung stattfinden, da gibt es dann Rundungsartefakte.
Interessanterweise verbrät samba gar nicht mal auffallend mehr CPU-Zeit als gatling. Das ist wohl einfach schlechtes Software-Design, was hier den Ausschlag gibt.
[zurück]
[ältere Posting][neuere Posting]
[zurück][ältere Posting][neuere Posting] Montag, 14 Januar 2008 | Blog: 5 | No: 10901
mencoder per smbclient eine smb:
55.11% done; got 382.9MiB of 694.7MiB in 7 sec (54.7MiB/sec), 5 sec to go.Und zwischen gatling und Notebook (dl):
40.64% done; got 282.4MiB of 694.7MiB in 5 sec (56.5MiB/sec), 7 sec to go.OK, das sieht ja schon mal verdächtig ähnlich aus. War im Grunde auch zu erwarten, schließlich benutzt auch samba heutzutage sendfile.
Das ist einfach so lahm, weil SMB die Dateien immer blockweise verschickt. D.h. man schickt einen Request, dass man 60k Datei ab Offset 0 haben will, dann liest man eine Antwort mit den Daten, dann schickt man den nächsten Request. Die Pipeline zwischen Server und Client bleibt immer stehen, wenn der gerade einen Request rausgeschickt hat, bis der nächste Request kommt. Da kommt dann mehrfach die Round Trip Zeit dazu, die Ethernet hat (das ist im Millisekundenbereich, aber das läppert sich).
Gut, aus dieser Erkentnis müsste man ja Kapital schlagen können. Also habe ich mal dl aufgehackt, damit er den nächsten Read Request immer schon rausschickt, wenn er gerade anfängt, die Antwort auf den letzten zu lesen. Hier gegen Samba:
85.81% done; got 596.1MiB of 694.7MiB in 10 sec (59.6MiB/sec), 1 sec to go.Und hier gegen gatling:
93.36% done; got 648.6MiB of 694.7MiB in 7 sec (92.7MiB/sec), 0 sec to go.Man sieht also: das lohnt sich. Allerdings auch nur dann, wenn die Server-Software nicht eh schon am Anschlag arbeitet :-)
Die 92 MB/sec sind schon recht nah an HTTP dran. Mit HTTP kriege ich im selben Szenario 97 MB/sec. Das ist, falls sich jemand fragt, deshalb nicht wire speed, weil
Interessanterweise verbrät samba gar nicht mal auffallend mehr CPU-Zeit als gatling. Das ist wohl einfach schlechtes Software-Design, was hier den Ausschlag gibt.
Twiter-Ticker
Fefes Latest Youtube Video Links
Der Betrieb der KraftZeitung kostet Geld. Da wir auch weiterhin unabhängig, überparteilich und ohne kommerzieller Werbung für Sie da sein wollen, sind wir auf Ihre Spende angewiesen. Vielen Dank.
