Hallo Zusammen,
ich arbeite seit geraumer Zeit an einer Art Dateiserver, ähnlich dem FTP aber mit ein paar Erweiterungen. Bislang lief alles problemlos, bei 100mbit Lan erreiche ich gut 11,48 MB/s. Bei diesem Test waren SATA Festplatten im Einsatz, sprich das Nadelöhr war das Lan.
Nun wollte ich mal eine Verbindung zu mir selbst aufbauen, um die Geschwindigkeit zu testen ohne Netzwerkverzögerung. Erwartet habe ich eine Rate von ca. 100 mb/s. Ich erreiche beim simplen Kopieren von Dateien etwa 110mb/s und dachte mir, dass das vlt. auch in etwa bei einer lokalen Verbindung so sein müsste oder vlt geringfügig darunter. Aber ich bekomme etwa 50mb/s hin.
Allerdings rede ich von durchschnittlichen 50mb/s. Als ich mir das über eine Progressbar visualisiert habe, habe ich gemerkt, dass Netty anscheinend nach einer gewissen Zeit einfach das Attribut "writable" eines Channels für ein paar Sekunden auf false setzt. Sprich es wird einfach nix mehr gesendet, auch die CPU Last sinkt innerhalb dieser Phase auf fast null... Und wenn dann mal geschrieben wird, sind es wieder 105 mb/s.
Nach einigen Tests hab ich nun eine Theorie: Ich lese und schreibe (Datei) innerhalb der Workerthreads, die ich anfangs Netty zugewiesen habe. Ich habe nun einfach Puffer verschickt, ohne sie durch einen Lesevorgang zu füllen. Sprich buffer.position(buffer.limit). Nun erreiche ich knapp 290 mb/s Durchsatz.
Ich habe das Gefühl, dass Netty merkt, wieviel Zeit ein Workerthread beschäftigt ist und wenn diese Zeit nciht adequat zur Verbindung passt, wird der Channel schlafen gelegt, bzw solange nicht auf Writable gesetzt bis irgendeiner Art Timeout abgelaufen ist wonach dann wieder mit dem Senden fortgefahren wird. Ich vermute, damit soll einer Art Überlastung durch einzelne
Workerthreads entgegen gewirkt werden.
Nun stell ich mir natürlich die Frage, wie man dieses Verhalten ändern könnte, bzw. vlt sogar nutzen könnte, um die ganze Geschichte fix zu machen.
Also wenn die Festplatten schneller sind, als das Netzwerk (ist ja eigentlich fast immer der Fall), so müsste immer dann ein neuer Part geschickt werden, sobald ein Teil geschickt wurde. Das wäre auch recht eifnach zu realisieren: Jeder Sendevorgang gibt ein Future Objekt zurück, über das man sich benachrichtigen lassen kann, sobald diese Operation fertig ist.
Ist das Netzwerk schneller, so müsste der Dateizugriff gewisserweise mit Future-Objekten versehen werden, damit immer dann, sobald ein neuer Teil gelesen wurde, ein Paket verschickt wird. Interessant könnte es dann noch bei unterschiedlich schnellen Festplatten werden...
Mach ich einen Denkfehler ? Ist das wirkliche Problem vlt. ein ganz anderes ?
@Tuxedo (Du wirst das ja bestimmt lesen ;-)):
Hast du ähnliche Erfahrungen schonmal mit MINA gemacht ? Weißt du zufälligerweise, wie sich dort Hochgeschwindigkeitsverbindungen verhalten ?
Gruß,
Chris
ich arbeite seit geraumer Zeit an einer Art Dateiserver, ähnlich dem FTP aber mit ein paar Erweiterungen. Bislang lief alles problemlos, bei 100mbit Lan erreiche ich gut 11,48 MB/s. Bei diesem Test waren SATA Festplatten im Einsatz, sprich das Nadelöhr war das Lan.
Nun wollte ich mal eine Verbindung zu mir selbst aufbauen, um die Geschwindigkeit zu testen ohne Netzwerkverzögerung. Erwartet habe ich eine Rate von ca. 100 mb/s. Ich erreiche beim simplen Kopieren von Dateien etwa 110mb/s und dachte mir, dass das vlt. auch in etwa bei einer lokalen Verbindung so sein müsste oder vlt geringfügig darunter. Aber ich bekomme etwa 50mb/s hin.
Allerdings rede ich von durchschnittlichen 50mb/s. Als ich mir das über eine Progressbar visualisiert habe, habe ich gemerkt, dass Netty anscheinend nach einer gewissen Zeit einfach das Attribut "writable" eines Channels für ein paar Sekunden auf false setzt. Sprich es wird einfach nix mehr gesendet, auch die CPU Last sinkt innerhalb dieser Phase auf fast null... Und wenn dann mal geschrieben wird, sind es wieder 105 mb/s.
Nach einigen Tests hab ich nun eine Theorie: Ich lese und schreibe (Datei) innerhalb der Workerthreads, die ich anfangs Netty zugewiesen habe. Ich habe nun einfach Puffer verschickt, ohne sie durch einen Lesevorgang zu füllen. Sprich buffer.position(buffer.limit). Nun erreiche ich knapp 290 mb/s Durchsatz.
Ich habe das Gefühl, dass Netty merkt, wieviel Zeit ein Workerthread beschäftigt ist und wenn diese Zeit nciht adequat zur Verbindung passt, wird der Channel schlafen gelegt, bzw solange nicht auf Writable gesetzt bis irgendeiner Art Timeout abgelaufen ist wonach dann wieder mit dem Senden fortgefahren wird. Ich vermute, damit soll einer Art Überlastung durch einzelne
Workerthreads entgegen gewirkt werden.
Nun stell ich mir natürlich die Frage, wie man dieses Verhalten ändern könnte, bzw. vlt sogar nutzen könnte, um die ganze Geschichte fix zu machen.
Also wenn die Festplatten schneller sind, als das Netzwerk (ist ja eigentlich fast immer der Fall), so müsste immer dann ein neuer Part geschickt werden, sobald ein Teil geschickt wurde. Das wäre auch recht eifnach zu realisieren: Jeder Sendevorgang gibt ein Future Objekt zurück, über das man sich benachrichtigen lassen kann, sobald diese Operation fertig ist.
Ist das Netzwerk schneller, so müsste der Dateizugriff gewisserweise mit Future-Objekten versehen werden, damit immer dann, sobald ein neuer Teil gelesen wurde, ein Paket verschickt wird. Interessant könnte es dann noch bei unterschiedlich schnellen Festplatten werden...
Mach ich einen Denkfehler ? Ist das wirkliche Problem vlt. ein ganz anderes ?
@Tuxedo (Du wirst das ja bestimmt lesen ;-)):
Hast du ähnliche Erfahrungen schonmal mit MINA gemacht ? Weißt du zufälligerweise, wie sich dort Hochgeschwindigkeitsverbindungen verhalten ?
Gruß,
Chris
