Bandbreite messen

[hotti]

hi,

mein Script auf dem Server gibt aus:

  
#!/usr/bin/perl  
  
$CGI::POST_MAX = 1024_0000;  
  
print "Content-type: text/plain\n\n";  
print $ENV{CONTENT_LENGTH};  

Dazu hab ich mir einen UA geschrieben, der sieht so aus:

  
#!/usr/bin/perl  
###########################################################################  
my $srv = "http://rolfrost.de/cgi-bin/responser.cgi";  
###########################################################################  
use strict;  
use LWP::UserAgent;  
use HTTP::Request::Common qw(POST);  
  
$| = 1;  
  
my $ua = LWP::UserAgent->new;  
  
my $chunk = 'a' x 100000;  
  
my $sta = time;  
my $req = POST $srv, Content => [x => $chunk];  
my $len = $ua->request($req)->content;  
my $sto = time;  
my $d = $sto - $sta;  
  
printf("%d Bit/s", 8 * $len / $d);  
  

Womit ich bei Messzeiten um 1 min so Bandbreiten um 10..20 kBit/s kriege (UMTS). Kann mal jemand von Euch mit dem Perl-UA über DSL|Kabel|Modem mal prüfen, ob der Test was taugt bzw. reproduzierbare Ergebnisse liefert?

Danke schonmal,
Horst Haselhuhn

[Ulli1956]

hi,

mein Script auf dem Server gibt aus:

Flasch, Dein Script spricht nicht mit mir!

Danke schonmal,

Bitte !!

Horst Haselhuhn

[hotti]

hi Ulli,

mein Script auf dem Server gibt aus:

Flasch, Dein Script spricht nicht mit mir!

Hast Du

  
$CGI::POST_MAX = 1024_0000;  

beachtet? Ab morgen hab ich wieder DSL, dann schaun mirma ob das Verfahren überhaupt geeignet ist. Wenn ja, wirds auf meiner Site demnächst ein Tool zur Bandbreitenmessung geben (ohne Werbung für die    B I L D  und ohne Angabe des Providers).

Viele Grüße,
Horst Haselhuhn

PS: Adventskalender ist fertig. Muss nur noch tippen.

[Alexander (HH)]

Moin Moin!

ein Tool zur Bandbreitenmessung

Du mißt, aber Du mißt nur Mist. (Und das liegt nur zum Teil an Dir, großenteils liegt es daran, wie das Internet funktioniert.)

Du mißt bestenfalls nur die Bandbreite an der engsten Stelle zwischen dem Benutzer und Deinem CGI. Bei UMTS, analogen Modems und erst recht GPRS / GSM ist das oft, aber nicht immer, die (virtuelle) Telefonleitung. Bei gut angebundenen Firmen- und Uni-Netzen kann das aber auch mal Dein Server sein. Der FTP-Server der GWDG ist (soweit ich mich erinnere) mit fast 1 GBit/s ans Internet angeschlossen (*NEID!*). Würde ich von dem gegen Deinen Server messen, in dem eine Fast Ethernet-Karte steckt, wird Deine Messung schon wegen Deiner Netzwerkkarte mindestens um Faktor 10 zu niedrig liegen.

Wenn - aus welchen Gründen aus immer - Dein Server überlastet ist, mißt Du, wie schnell Dein Server noch Daten liefern kann. Bei VHosts und erst recht bei Shared Hosting hast Du keine Kontrolle darüber, wie viel Last anliegt.

Wenn die Anbindung des RZs, in dem "Dein" Server steht, überlastet ist, mißt Du, wie viel Bandbreite Deinem Server noch zur Verfügung steht.

Wenn die (Netz-)Nachbarn Deines Besuchers wie blöd riesige Datenmengen ziehen, wird Dein Besucher kaum noch Bandbreite zum Internet haben, obwohl sein Zugang längst nicht ausgelastet ist.

Wenn auf dem Rechner Deines Besuchers im Hintergrund noch etwas herunterlädt (z.B. Windows Update, Acrobat Update, Flash Update, Java Update ... - alle oft nicht auf dem Bildschirm zu erkennen), steht Dein Tool mit den Downloads in Konkurrenz und Du mißt nur Restbandbreite.

An meinem Arbeitsplatz habe ich spaßeshalber mal den Blöd-Test laufen lassen. Die Internet-Anbindung ist in der Größenordnung DSL 6000, aber trotzdem attestiert mir das Tool eine "Breitband-Anbindung" mit rund 90 MBit/s. Haben die Telekomiker da am DSL was falsch eingestellt? Nö! Viel einfacher: Das ist meine LAN-Anbindung am Arbeitsplatz, denn zwischen PC und Server steht ein Proxy, der erst einmal die gesamte angeforderte Seite selbst herunterlädt und dann weiterreicht. Das Tool mißt die Ladezeit innerhalb der Seite mit Inline-Javascript, und die sind über ein geswitches Fast Ethernet LAN eben knackig kurz.

Dein Tool [ Ah, gerade gesehen: Du rätst am Upload, nicht am Download. Das ändert am Problem aber fast gar nichs, und deswegen ignoriere ich das mal weiterhin. ] startet die Uhr schon vor dem HTTP-Request. Damit fließt in die Messung auch die Zeit ein, die der Besucher-Rechner damit vertrödelt, Deinen Hostnamen auf eine IP-Adresse umzusetzen. Das kann je nach Umgebung, Provider und Anbindung ein oder zwei digitale Ewigkeiten dauern. Viel besser wäre, erst beim Connect die Uhr zu starten.

Außerdem multiplizierst Du die Größe der Nutzdaten stumpf mit 8, um auf die übertragenen Bits zu kommen. Die HTTP-Header unterschlägst Du komplett, ebenso die zusätzlichen Bytes, die TCP und IP hinzufügen. Faktor 10 oder 11 bildet die Realität in Ethernet-Netzwerken schon etwas besser ab.

Und schließlich überträgst Du extrem leicht komprimierbare Daten. gzip komprimiert Deine 100.000 Bytes auf schlappe 139 Bytes, bzip2 läßt sogar nur 47 Bytes stehen. Wenn unterwegs komprimiert wird (transparenter Zwangsproxy), erscheint die Bandbreite viel zu hoch - so ungefähr Faktor 1000 oder 2000, wenn die Komprimierung schnell geht. Nimm also Rauschen statt konstanter Werte.

Alexander

[hotti]

hi Alexander,

danke für Deine Hinweise.

[..] Die HTTP-Header unterschlägst Du komplett, ebenso die zusätzlichen Bytes, die TCP und IP hinzufügen.

Request- und ResponseHeader kann ich rausrechnen mit einer Differenzmessung (derzeit von Hand).

Und schließlich überträgst Du extrem leicht komprimierbare Daten.

Das ist auch richtig. Ein realistisches Ergebnis zu erhalten ist möglich, wenn die Leitung sozusagen "zugeballert" wird, das hab ich schonmal mit ICMP gemacht und das gibt auch reproduzierbare Ergebnisse. Inwieweit sowas mit HTTP überhaupt möglich ist, muss ich mir nochmal anschauen.

Btw., schau Du Dir mal das Tool pathchar an (Flaschenhals finden).

Viele Grüße,
Horst Haselhuhn

[Ulli1956]

Hallo Horst,

[...] Wenn ja, wirds auf meiner Site demnächst ein Tool zur Bandbreitenmessung geben (ohne Werbung für die    B I L D  und ohne Angabe des Providers).

Okay, dann warte ich.... [finger_trommel]

PS: Adventskalender ist fertig. Muss nur noch tippen.

Nuex gefunden!

bis dann

Ulli