optimale HTTP Downloads

[Kevin1990]

Hi,

ich hätte mal eine allgemeine Frage zu http downloads.
Im Moment lade ich mit folgendem Code herunter:

   String link = "..."; //irgendein Link
   String filename = "..."; //irgendein Dateiname
   URL url = new URL(link);
   InputStream is = url.openConnection.getInputStream();
   OutputStream os = new FileOutputStream(filename);
   byte[] buffer = new byte[4096];
   int rc;

   while((rc = is.read(buffer)) != -1) {
      out.write(buffer, 0, rc);
   }
   out.flush();
   out.close();

Nun wenn ich in die Netzwerküberwachung schaue, fällt mir auf, dass immer für 10s geladen wird, dann 5s nicht, dann wieder 10s usw.

Woran könnte dies liegen?

Vielen Dank schonmal

mfg
Kevin[/code]

 

[foobar]

Das liegt vielleicht am Webserver oder an deiner Leitung. Haste das mal mit unterschiedlichen Urls getestet?

 

[xote]

Liegts vielleicht am Buffer?

 

[Kevin1990]

so ich habe verschiedenste Buffergrößen getestet und dabei ist mir aufgefallen, dass wenn die Downloadgeschwindigkeit durch eine zu geringe Buffergröße limitiert wird, der Download wunderbar läuft.

Wähle ich allerdings die Buffergröße zu hoch, so wirkt es so, als ob der Webserver nach einigen angeforderten Kilobytes blockiert und das Programm solange in der read() - Funktion verweilt bis neue Daten vom Server geliefert werden.

 

[tuxedo]

Bei normalen Webseiten würde ich den Buffer nicht auf 4096 belassen. Da würde ich vielleicht 512 oder 1024 nehmen.

Für Filedownloads machen dann Werte >1024 schon mehr Sinn.

Gruß
Alex

 

[Guest]

Ich muss gestehen ich habe nur geraten, ich bin auch java anfänger ;-)

 

[xote]

Und zu doof, mich richtig im Forum anzumelden bin ich auch...

Ich habe mich schon immer gefragt, wie das mit den Buffergrößen so ist.

 

[Kevin1990]

also danke für die Antworten ... ich habe mir jetzt selbst nen Algorithmus ausgedacht, der das ganze etwas glättet:

int receivedBytes;
int sleepTime = 0;
int counter = -1;
byte[] buffer = new byte[2048];
long before = System.currentTimeMillis();
long last = 0;

while ((receivedBytes = is.read(buffer)) > -1) {
  try {
    Thread.sleep(sleepTime);
  } catch (InterruptedException interrupted) {
    interrupted.printStackTrace();
  }
  long after = System.currentTimeMillis();
  // Zeit der Paketanforderung vom Server  
  long difference = before - after;
  long current = difference;   
  // vergleich der Zeiten zwischen dem aktuellen und dem letzten Schleifendurchlauf
  if (Math.abs(current - last) > 100)) {
    if(last!=0) {
      sleepTime += 2;
    }
  }
  long last = current;
  os.write(buffer, 0, receivedBytes);
  before = System.currentTimeMillis();
}

MfG

 

[HoaX]

was soll das schlafen bringen? einen geschwindigkeitszuwachs im ganzen wirst du damit nicht bekommen imo

 

[Kevin1990]

Es ging mir mehr oder wengier nur darum, eine konstante Geschwindigkeit zu erhalten. Und meine jetzige Lösung vermeidet diese ständigen Wechsel zwischen 0 kb/s und 500 kb/s.

 

[HoaX]

was hast du davon wenn er (scheinbar) konstant ist, dafür aber langsamer?
bist du sicher dass das messinstrument richtig funktioniert? mal andere probiert?

 

[tuxedo]

Was hälst du davon die Transfergeschwindigkeit mal direkt im Java-Code zu messen? Ich tippe mal darauf dass dein Messinstrument quatsch produziert.

 

[cschaedl]

Mein Messgerät produziert keinen Quatsch
getestet unter Win XP, Ubuntu und MacOS
auch unter verschiedenen Rechnern


überall das gleiche Problem und im Javacode hab ichs auch bereits getestet ... genau das gleiche.

 

[tuxedo]

Also ich kann dir nur sagen, dass ich mit UrlConnections Megabyteweise Daten von unterschiedlichen URLs (lokal, via Internet, ...) saugen kann ohne dass es zu solchen Einbrüchen kommt. Im lokalen Netzwerk komme ich nahezu an die 10MB/sek ran. Im Internet mit DSL6000 und einem guten Server zwischen 600 und 700kbyte/sek.

Gemessen hab ich das bei HTTP und HTTPS
a) direkt in Java in dem ich die eingehenden bytes am InoutStream gezählt habe
b) In Windows (XP) mit dem Tool "DuMeter"
c) Unter Linux (Debian und openSuSE) mit gkrellm

Damit schließe ich Java als "Fehlerquelle" für das von dir beschriebene Verhalten aus.

Was bei dir so ein Verhalten produziert: Kein Plan.

- Alex

 

[cschaedl]

Deine Daten stimmen schon ... bei mir funktioniert das auch weitestgehend problemlos, allerdings kommt es bei einigen "wenigen" Webservern zu dem geschilderten Problem. Vor allem bei denjenigen, die einen limitierten Traffic besitzen.

@Hoax ... durch diesen ständigen Wechsel der Download-Geschwindigkeit, wird die CPU stärker beansprucht. Im Schnitt habe ich dadurch 2% mehr CPU-Auslastung als bei konstanter Download-Geschwindigkeit.

 

[tuxedo]

>> allerdings kommt es bei einigen "wenigen" Webservern zu dem geschilderten Problem. Vor allem bei denjenigen, die einen limitierten Traffic besitzen.

Aha, und damit rückst du erst jetzt raus.... ?

>> @Hoax ... durch diesen ständigen Wechsel der Download-Geschwindigkeit, wird die CPU stärker beansprucht. Im Schnitt habe ich dadurch 2% mehr CPU-Auslastung als bei konstanter Download-Geschwindigkeit.

Bitte was? Wenn man sauber programmiert hat und keine Billig-VomLasterGefallen-SüdostasienHinterhof-Netzwerkkarte hat, dann ist der CPU die Last auf dem Netzwerk sowas von egal....
Klar, bei manchen Mainboards mit OnBoard Netzwerk übernimmt die CPU die Steuerung der Netzwerkkarte. Aber ich kann nicht glauben, dass bei einem Download aus dem Internet mit den paar kilobyte/sek (man beachte die Prozentuele Netzauslastung der Karte) die CPU mit 2% mehr belastet wird, vor allem wenn der Traffic stark schwankt...

Und selbst wenn das so wäre (ich gehe davon aus dass die Empfangsroutine noch irgendwo im Code ne Macke hat), dann bremst du nochmal zusätzlich künstlich den Stream, nur um wahnsinnige 2% CPU zu sparen? Mag sein dass die Lösung mit den momentan bekannten Problemfällen funktioniert, aber was ist mit dem nächsten der evtl anders drauf reagiert und die Sache dann nochmal weiter gebremst wird? Nur um wahnsinnige 2% zu sparen riskirst du, dass der User nicht die max. mögliche Geschwindigkeit bekommt.

Naja, jedem das Seine.

- Alex