Java NIO Urlconnection Filetransfer

[CHAOSFISCH]

Servus,

ich versuch grad meinen Fileupload umzustellen auf Java7.
Soweit ich informiert bin ist Java NIO besser als IO in Bezug auf Performance.
Sehr gerne würde ich den Fileupload mit Apache HTTPClient machen, jedoch ist hier wichtig zu erwähnen, dass es sich um einen Chunkedupload zu Youtube handelt - eine Möglichkeit dies daher zu verwenden habe ich nicht gefunden.

Hat jemand hier vielleicht ein Beispiel für die Verwendung von HTTPClient chunk upload oder Java NIO UrlConnection upload?

Gruß
CHAOSFISCH

 

[Bernd Hohmann]

Wenn Du nicht gerade spezielle Sachen brauchst (wie asynchrone Bedienung der Sockets) dauert die Umstellung auf NIO länger Du jemals an Geschwindigkeitsvorteilen herausholen wirst. Die Bremse ist das Netz selbst, nicht java.net.*

Bernd

 

[CHAOSFISCH]

Wenn Du nicht gerade spezielle Sachen brauchst (wie asynchrone Bedienung der Sockets) dauert die Umstellung auf NIO länger Du jemals an Geschwindigkeitsvorteilen herausholen wirst. Die Bremse ist das Netz selbst, nicht java.net.*

Bernd

Zeitlich habe ich kein Problem damit 😛
Performancetechnisch erhoffe ich mir vor allem bei den Glasfaserusern eine Verbesserung. Diese haben teils unterirdische Uploadgeschwindigkeiten unabhängig von der Chunkgröße.
Zumal dann noch die 2. Frage von mir: Ist das ganze sinnvoll mit HttpClient umsetzbar?
- eine manuelle UrlConnection bringt sehr viel Fehlerpotential mit.

Gruß
CHAOSFISCH

 

[Spacerat]

Wenn Du nicht gerade spezielle Sachen brauchst (wie asynchrone Bedienung der Sockets) dauert die Umstellung auf NIO länger Du jemals an Geschwindigkeitsvorteilen herausholen wirst. Die Bremse ist das Netz selbst, nicht java.net.*

Bernd

Hehe... da ist was dran.

Die Performancevorteile von Java NIO geniesst man nur innerhalb der VM. Das hat etwas mit der Pufferverwaltug innerhalb dieser zu tun, genauer gesagt, ob die Puffer im JVM-Heap oder im BS-Speicher (DirectBuffer) angelegt werden. Wenn man so will (und es vor allem noch kennt XD) könnte man DirectBuffer mit dem Graphics-Mem und den Heap mit dem Fast-Mem eines Amigas vergleichen. DirectBuffer können von der JVM direkt (per Referenz) an das BS übergeben werden und so BS weit (Alice, Paula, Lisa, 68k) genutzt werden. Auf den Heap hat aber nur die VM (nur 68k) Zugriff.
Okay, der Vergleich hinkt etwas, zumal der Heap plötzlich der schnellere (Fast-Mem) Speicher sein müsste. Jedoch fallen unterschiedliche, harwarebedingte Zugriffszeiten beider Speicherarten logischerweise weg, ebenso der hardware synchronisierte Zugriff (DMA) und es bleibt nur noch die Kenntnis/Erreichbarkeit der Speicheradressen übrig. Deswegen können DirectBuffer durchaus performanter sein.

 

[CHAOSFISCH]

Hehe... da ist was dran.

Die Performancevorteile von Java NIO geniesst man nur innerhalb der VM. Das hat etwas mit der Pufferverwaltug innerhalb dieser zu tun, genauer gesagt, ob die Puffer im JVM-Heap oder im BS-Speicher (DirectBuffer) angelegt werden. Wenn man so will (und es vor allem noch kennt XD) könnte man DirectBuffer mit dem Graphics-Mem und den Heap mit dem Fast-Mem eines Amigas vergleichen. DirectBuffer können von der JVM direkt (per Referenz) an das BS übergeben werden und so BS weit (Alice, Paula, Lisa, 68k) genutzt werden. Auf den Heap hat aber nur die VM (nur 68k) Zugriff.
Okay, der Vergleich hinkt etwas, zumal der Heap plötzlich der schnellere (Fast-Mem) Speicher sein müsste. Jedoch fallen unterschiedliche, harwarebedingte Zugriffszeiten beider Speicherarten logischerweise weg und es bleibt nur noch die Kenntnis/Erreichbarkeit der Speicheradressen übrig. Deswegen können DirectBuffer durchaus performanter sein.

Ja okay, was kann dann der Grund sein, dass Glasfaser oder Rootserver-Anbindungen es nicht schaffen mit voller Leistung ähnlich dem Browserfenster hochzuladen? Chunksize? Standard 10MB, kann auf bis zu 500MB erhöht werden - keine richtige Veränderung. Input byteBuffer-Größe? 8192 zu klein?

 

[Spacerat]

Ja okay, was kann dann der Grund sein, dass Glasfaser oder Rootserver-Anbindungen es nicht schaffen mit voller Leistung ähnlich dem Browserfenster hochzuladen? Chunksize? Standard 10MB, kann auf bis zu 500MB erhöht werden - keine richtige Veränderung. Input byteBuffer-Größe? 8192 zu klein?

Relativ einfach... wenn etwas mit nur 10MBit gesendet wird, kann es auch nur mit 10MBit empfangen werden, da kannst du Millarden Bytes als Puffer haben, die werden brach liegen. In die andere Richtung (1000MBit -> 10MBit) lohnen sich grössere Puffer (>8k) meistens auch nicht.

 

[CHAOSFISCH]

Relativ einfach... wenn etwas mit nur 10MBit gesendet wird, kann es auch nur mit 10MBit empfangen werden, da kannst du Millarden Bytes als Puffer haben, die werden brach liegen. In die andere Richtung (500MBit -> 10MBit) lohnen sich grössere Puffer (>8k) meistens auch nicht.

Ich sprach von 10Megabyte Chunkgröße bis 500 Megabyte. War jetzt MB Megabyte oder Mb - ich dachte MB!
500 Megabyte / s schafft keine Rootserver-Anbindung und wäre mehr als was eine standard Glasfaserverbindung pro Sekunde schaffen kann (Ich rede hier von FTTH).

 

[Spacerat]

Ich sprach von 10Megabyte Chunkgröße bis 500 Megabyte. War jetzt MB Megabyte oder Mb - ich dachte MB!
500 Megabyte / s schafft keine Rootserver-Anbindung und wäre mehr als was eine standard Glasfaserverbindung pro Sekunde schaffen kann (Ich rede hier von FTTH).

Das ist egal. 😉
Aber das Ganze gerne noch mal in MB/s (Ich rechne da mal schlicht /8). Wenn man nur 1,25MB/s sendet, kann man keine 125MB/s empfangen. Das ist von einer Puffergrösse völlig unabhängig.

 

[CHAOSFISCH]

Das ist egal. 😉
Aber das Ganze gerne noch mal in MB/s (Ich rechne da mal schlicht /8). Wenn man nur 1,25MB/s sendet, kann man keine 125MB/s empfangen.

Wir müssen irgendwo aneinander vorbeireden.
Upload im Browser (Java-applet von Google) = 100% Leistung
Upload in Javanwendung = 10% Leistung
bei schnellen Verbindungen.
Was ist also falsch?

 

[Spacerat]

Wir müssen irgendwo aneinander vorbeireden.
Upload im Browser (Java-applet von Google) = 100% Leistung
Upload in Javanwendung = 10% Leistung
bei schnellen Verbindungen.
Was ist also falsch?

Evtl. liegts am Buffering beim Sender. Da sollte man dem Stream eine Pipe vorschalten. Das erfordert zwar mindestens einen Thread mehr, sorgt aber dafür, dass ausschlieslich gefüllte Buffer gesendet werden, sofern nicht gedrained oder geflusht wird.

 

[CHAOSFISCH]

Evtl. liegts am Buffering beim Sender. Da sollte man dem Stream eine Pipe vorschalten. Das erfordert zwar mindestens einen Thread mehr, sorgt aber dafür, dass ausschlieslich gefüllte Buffer gesendet werden, sofern nicht gedrained oder geflusht wird.

Okay, das werd ich dann mal googlen. Brauch aber ein zwei Tage für eine Bestätigung ob damit das "Problem" gesolved wurde.

 

[Bernd Hohmann]

Wir müssen irgendwo aneinander vorbeireden.
Upload im Browser (Java-applet von Google) = 100% Leistung
Upload in Javanwendung = 10% Leistung
bei schnellen Verbindungen.
Was ist also falsch?

Da fallen mir eine Menge Fehlerquellen ein deren Behebungen abseits von java.nio liegen.

Das Java-Applet von Google könnte dir zB. den nächsten Uploadserver mit den geringsten Hops dazwischen zuweisen oder welcher die geringsten Routingkosten oder Latenzen hat.

Ich mache zu viel mit dem Dreck als dass ich bei Deiner Frage sagen kann "das ist die wahrscheinlichste Lösung!"

Bernd

 

[CHAOSFISCH]

Da fallen mir eine Menge Fehlerquellen ein deren Behebungen abseits von java.nio liegen.

Das Java-Applet von Google könnte dir zB. den nächsten Uploadserver mit den geringsten Hops dazwischen zuweisen oder welcher die geringsten Routingkosten oder Latenzen hat.

Ich mache zu viel mit dem Dreck als dass ich bei Deiner Frage sagen kann "das ist die wahrscheinlichste Lösung!"

Bernd

Gut selbst wenn das der Fall ist, so hätte ich dann eine Information die ich dann als Enhancement Issue weiterleiten könnte. Nur will ich hier auch grundlegend schonmal eine "optimale" Lösung in der Anwendung haben, so dass man möglichst eindeutig den Server für das Problem verantwortlich machen kann.

 

[Bernd Hohmann]

Wenn dem so ist, dann ist dem halt so.

Bernd

 

[CHAOSFISCH]

Wenn dem so ist, dann ist dem halt so.

Bernd

So, der Fehler scheint nun gefunden - muss das nur noch mit Glasfasergeschwindigkeiten testen - Rootserver Geschwindigkeiten werden erreicht.
Die Buffergröße war viel zu klein (8kb). Jetzt beträgt sie 64kb, gibts da eigentlich eine idealgröße?