Kein HTTP-Pipelining?
Hauke Laging
über eine Diskussion (<7qfh4q...@mid.uni-berlin.de>), die ich in
de.comm.infosystems.www.authoring.misc losgetreten habe, bin ich
darauf gekommen, dass die Browser (kein reines FF-Problem) Webseiten
offenbar nicht per Pipelining laden (nicht mal Chrome!).
Bei naiver Betrachtung erscheint das total schwachsinnig. Nach dem
Parsen des HTML-Dokuments kennt der Browser (fast) alle zu ladenden
Dateien und könnte die en bloc anfordern. Tut er das, aber die
Server unterstützen es nicht?
CU
Sascha Grage
> Moin,
> �ber eine Diskussion (<7qfh4q...@mid.uni-berlin.de>), die ich in
> de.comm.infosystems.www.authoring.misc losgetreten habe, bin ich
> darauf gekommen, dass die Browser (kein reines FF-Problem) Webseiten
> offenbar nicht per Pipelining laden (nicht mal Chrome!).
> Bei naiver Betrachtung erscheint das total schwachsinnig. Nach dem
> Parsen des HTML-Dokuments kennt der Browser (fast) alle zu ladenden
> Dateien und k�nnte die en bloc anfordern. Tut er das, aber die
> Server unterst�tzen es nicht?
Pipelining kann man einschalten. Default ist aus.
bye,
Sascha
Dietmar Hollenberg
> �ber eine Diskussion (<7qfh4q...@mid.uni-berlin.de>), die ich in
> de.comm.infosystems.www.authoring.misc losgetreten habe, bin ich
> darauf gekommen, dass die Browser (kein reines FF-Problem) Webseiten
> offenbar nicht per Pipelining laden (nicht mal Chrome!).
Der Firebug erz�hlt mir aber etwas anderes. FF l�dt *alle* Daten immer
in dem Moment, in dem er von der Notwendigkeit erf�hrt. Also alle
Dateien aus dem Grundger�st gleich nach dem Laden dieser Datei, alle
Hintergrundbilder und Zusatzdateien in CSS-Dateien, sobald die
CSS-Dateien verarbeitet sind, alle von Scripten, sobald die
Scriptausf�hrung an dem entsprechenden Punkt angekommen ist. Die
Anforderungen kommen so parallel, wie das HTTP es zul��t, und es werden
so viele gleichzeitig geladen, wie der Server Verbindungen aufbaut.
Tsch��
Dietmar
--
Lesbar quoten kann so einfach sein:
http://www.learn.to/quote
http://www.volker-gringmuth.de/usenet/zitier.htm
Hauke Laging
> Pipelining kann man einschalten. Default ist aus.
Das ist ja geil. Warum das denn?
Und wie schaltet man es ein?
Hauke Laging
> Der Firebug erzählt mir aber etwas anderes.
Wusste gar nicht, dass der das kann.
> Also
> alle Dateien aus dem Grundgerüst gleich nach dem Laden dieser
> Datei, alle Hintergrundbilder und Zusatzdateien in CSS-Dateien,
> sobald die CSS-Dateien verarbeitet sind, alle von Scripten, sobald
> die Scriptausführung an dem entsprechenden Punkt angekommen ist.
Es geht aber nicht um das Wann, sondern das Wie!
Ich hatte bei der Ausgabe des Add-ons "Live HTTP headers" nicht den
Eindruck, dass die Anforderungen gebündelt werden. Allerdings weiß
ich nicht, ob das Add-on seine Ausgabe so zusammenbastelt, dass man
das gar nicht sehen kann.
> Die Anforderungen kommen so parallel, wie das HTTP es zuläßt, und
> es werden so viele gleichzeitig geladen, wie der Server
> Verbindungen aufbaut.
Das ist ja gerade das Gegenteil von Pipelining. Wenn man das nutzt,
ist es Unsinn, eine zweite HTTP-Verbindung aufzubauen, weil die
Bandbreite nicht höher wird. Ausnahme sind Situationen, in denen die
Bedarfsliste erweitert wird (z.B. durch Referenzen auf Bilder in
CSS-Dateien, wie von Dir angesprochen).
http://de.wikipedia.org/wiki/HTTP-Pipelining
Burkhard Müller
> Sascha Grage schrieb am Donnerstag 07 Januar 2010 14:35:
>
>> Pipelining kann man einschalten. Default ist aus.
>
> Das ist ja geil. Warum das denn?
>
> Und wie schaltet man es ein?
about:config, filtern auf "pipelining"
HTH, BM
Simon Paquet
>> Pipelining kann man einschalten. Default ist aus.
>
> Das ist ja geil. Warum das denn?
Es gibt zu viele schlecht konfigurierte Server da drau�en bzw. Server,
die verbugte HTTP-Server Software benutzen.
Deswegen ist Pipelining ausgeschaltet, weil der gemeine User nicht
erkennen kann, warum pl�tzlich eine Website, die vorher immer bei ihm
funktioniert hat, nicht mehr funktioniert. Man f�rchtet bei Mozilla
(und bei allen anderen Browser-Herstellern), dass die User dann den
Browser hierf�r verantwortlich machen und nicht den Server-Betreiber.
--
Simon Paquet
Dietmar Hollenberg
> Ich hatte bei der Ausgabe des Add-ons "Live HTTP headers" nicht den
> Eindruck, dass die Anforderungen geb�ndelt werden.
Definiere "geb�ndelt".
Sie gehen nicht als eine Anforderung raus, aber so unmittelbar
hintereinander, wie es HTTP zul��t. Die Zeitverz�gerungen im ms-Bereich
sind bestenfalls me�bar, aber niemals f�hlbar. Alle anderen
Verz�gerungen wirken sich um Faktor 1000 st�rker aus.
Die Antworten werden so schnell parallel gelesen, wie der Server sie
schickt und die Bandbreite des Netzes es zul��t.
So jedenfalls zeigt der Firebug es in seinen Timelines, und das
summierte Endergebnis ist plausibel.
> http://de.wikipedia.org/wiki/HTTP-Pipelining
Genau das sehe ich in der Anzeige im Firebug.
Genau bei dieser Seite als Beispiel: Als erstes wird die Datei
http://de.wikipedia.org/wiki/HTTP-Pipelining
geladen. Sobald sie eingelesen ist, gehen *gleichzeitig* alle
Anforderungen f�r die darin enthaltenen Dateien raus, z.B.
http://de.wikipedia.org/w/extensions/UsabilityInitiative/css/combined.min.css?16
http://de.wikipedia.org/w/extensions/UsabilityInitiative/css/vector/jquery-ui-1.7.2.css?1.7.2
http://de.wikipedia.org/skins-1.5/common/shared.css?257z2
usw.
Wenn in einer dieser Dateien weitere Anforderungen enthalten sind, gehen
sie unmittelbar nach der Interpretation dieser Datei raus, aber wieder
alle gleichzeitig.
Es ist *nicht* so, da� grunds�tzlich die n�chste Anforderung erst
abgeschickt wird, wenn die aktuelle vom Server beantwortet wurde.
Martin Schoenbeck
Dietmar Hollenberg schrieb:
> Es ist *nicht* so, da� grunds�tzlich die n�chste Anforderung erst
> abgeschickt wird, wenn die aktuelle vom Server beantwortet wurde.
Sie gehen aber nicht �ber eine Verbindung raus, sondern es wird jeweils
eine neue Verbindung aufgebaut. Pipelining macht das �ber eine Verbindung.
Gru� Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die pa�t so.
Dietmar Hollenberg
> Sie gehen aber nicht �ber eine Verbindung raus, sondern es wird jeweils
> eine neue Verbindung aufgebaut. Pipelining macht das �ber eine Verbindung.
Ok, man gewinnt ein paar Ping-Zeiten. Ich konnte hier gerade bei ein
paar Tests keine Beschleunigung au�erhalb der Me�toleranz feststellen.
Der maximale Zeitgewinn war bei ein paar zuf�llig ausgew�hlten Seiten
auf verschiedenen Servern kleiner als die Ladezeitstreuung bei
mehrmaligem Laden ohne Cache.
Robert Kochem
> Das ist ja gerade das Gegenteil von Pipelining. Wenn man das nutzt,
> ist es Unsinn, eine zweite HTTP-Verbindung aufzubauen, weil die
> Bandbreite nicht h�her wird.
Das galt fr�her bei der Einwahl �ber Modem und ISDN vielleicht, aber im
DSL-Zeitalter ist die Praxis eine Andere.
Au�erdem behandelt das Internet jeden TCP-Stream unabh�ngig von den
Anderen. D.h. wenn es einen Stau irgendwo gibt bekommt man mit mehreren
Streams eine h�here Datenrate. Das ist ja genau das Problem, dass die
Provider den Filesharern vorwerfen.
BTW: Nach deiner Definition d�rften Tools, die aus mehreren Quellen
gleichzeitig eine Datei herunterladen nicht schneller sein als der normale
Download im browser aus einer Quelle.
Robert
Hauke Laging
> Es gibt zu viele schlecht konfigurierte Server da draußen bzw.
> Server, die verbugte HTTP-Server Software benutzen.
Aber man könnte doch ein Whitelisting für kompetente Serversoftware
nutzen. Oder melden sich etwa Server mit einer falschen Kennung (wie
manche Browser es – die allerdings aus gutem Grund – tun)?
> Deswegen ist Pipelining ausgeschaltet, weil der gemeine User nicht
> erkennen kann, warum plötzlich eine Website, die vorher immer bei
> ihm funktioniert hat, nicht mehr funktioniert.
Nächster Gedanke: Der Browser merkt doch, ob er die Seite laden kann.
Wie sollte denkbar sein, dass ein Server beim Pipelining versagt,
der Browser das aber nicht mitkriegt? Eben, kann man vergessen. Auch
der dümmste Server wird ja wohl kaum falsche Daten liefern. Und
selbst wenn das passiert, könnte man zur Sicherheit einfach alles
verwerfen. Also: Einmal pro Domain Pipelining versuchen, bei
Problemen für diese Domain deaktivieren (bis sich die
Webserverkennung ändert oder bis zum nächsten Browserstart) und die
Seite noch mal laden.
> Man fürchtet bei
> Mozilla (und bei allen anderen Browser-Herstellern), dass die User
> dann den Browser hierfür verantwortlich machen und nicht den
> Server-Betreiber.
Verständlich. Aber zumindest für die großen Webseiten könnte man eine
Whitelist beilegen. Immerhin erfreut sich Firefox auch an einer
50-MiB-Blacklist.
Das Problem kann ich nachvollziehen, den passiven Umgang damit nicht.
![Ulf [Kado] Kadner's profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWS0V3TJwJ-07-NWcLG9HZ4SMFbgzyAMxottO1QqD5V2n_1h37R=s40-c)
Ulf [Kado] Kadner
> Aber man könnte doch ein Whitelisting für kompetente Serversoftware
> nutzen. Oder melden sich etwa Server mit einer falschen Kennung (wie
> manche Browser es – die allerdings aus gutem Grund – tun)?
Die Serverkennung ist nicht zuverlässiger als die Browserkennung. Warum
sollte man Infos die einen Server u.U angereifbarer machen als Server die
falsche oder Keine Infos zu sich senden wollen?
> Nächster Gedanke: Der Browser merkt doch, ob er die Seite laden kann.
> Wie sollte denkbar sein, dass ein Server beim Pipelining versagt, der
> Browser das aber nicht mitkriegt?
Das würde voraussetzen das Pipelining als Fehlerquelle erkennbar ist um
darauf irgendwie reagieren zu können. Keine Ahnung ob das so machbar ist.
MfG, Ulf
--
Eine Semmel enthält 140 Kalorien, 700 Semmeln pro Jahr ergeben 98000
Kalorien, diese benötigt man, um eigenhändig 1 Elefanten 9 Zentimeter
weit zu tragen. Aber wozu? [Loriot]
Hauke Laging
> Hauke Laging schrieb:
>
>> Ich hatte bei der Ausgabe des Add-ons "Live HTTP headers" nicht
>> den Eindruck, dass die Anforderungen gebündelt werden.
>
> Definiere "gebündelt".
Wovon handelt denn der Thread? HTTP-Anforderungen zu bündeln ist
Pipelining.
> Sie gehen nicht als eine Anforderung raus, aber so unmittelbar
> hintereinander, wie es HTTP zuläßt. Die Zeitverzögerungen im
> ms-Bereich sind bestenfalls meßbar, aber niemals fühlbar. Alle
> anderen Verzögerungen wirken sich um Faktor 1000 stärker aus.
So sieht heise.de bei mir in Chrome aus:
http://www.hauke-laging.de/dciwam/seitenaufbau-downloadzeiten.png
Ich weiß leider nicht, wie ich mir das in Firefox anzeigen lassen
kann. Jedenfalls sind die Latenzen, die bei Pipelining ja wegfallen,
der dominante Teil.
> Die Antworten werden so schnell parallel gelesen, wie der Server
> sie schickt und die Bandbreite des Netzes es zuläßt.
Das ist klar, aber die Bandbreite wird durch parallele Übertragung
nicht höher.
> So jedenfalls zeigt der Firebug es in seinen Timelines
Wie kommt man denn da ran?
>> http://de.wikipedia.org/wiki/HTTP-Pipelining
>
> Genau das sehe ich in der Anzeige im Firebug.
Diese Grafik ist fehlerhaft/irreführend, wie ich schon auf der
Diskussionsseite des Artikels erklärt habe... :-)
> Sobald sie eingelesen ist, gehen *gleichzeitig* alle
> Anforderungen für die darin enthaltenen Dateien raus
Was heißt das auf HTTP-Ebene? Pipelining oder parallele Verbindungen,
oder nur browserinternes Vormerken zum Download?
Hauke Laging
> Das würde voraussetzen das Pipelining als Fehlerquelle erkennbar
> ist um darauf irgendwie reagieren zu können. Keine Ahnung ob das so
> machbar ist.
Na, ja, wenn man den Download nach einem Fehler wiederholt, der aber
bestehenbleibt, weil es nicht am Pipelining lag, dann hat man
jedenfalls nichts verloren, oder? :-)
Martin Schoenbeck
Hauke Laging schrieb:
> N�chster Gedanke: Der Browser merkt doch, ob er die Seite laden kann.
> Wie sollte denkbar sein, dass ein Server beim Pipelining versagt,
> der Browser das aber nicht mitkriegt? Eben, kann man vergessen. Auch
> der d�mmste Server wird ja wohl kaum falsche Daten liefern.
Zumal rfc 2616 vom Client ausdr�cklich fordert, damit umgehen zu k�nnen,
wenn der Server das Pipelining abbricht.
Wenn's aber im Ergebnis ohnehin kaum etwas bringt, dann bleibt man
nat�rlich lieber auf der sicheren Seite.
Martin Schoenbeck
Robert Kochem schrieb:
> BTW: Nach deiner Definition d�rften Tools, die aus mehreren Quellen
> gleichzeitig eine Datei herunterladen nicht schneller sein als der normale
> Download im browser aus einer Quelle.
Wie kommst Du auf die Schnapsidee? Er _will_ ja alle Daten aus einer
Quelle. Wenn die der Engpa� ist und nicht mehr rausr�ckt, ist das eben
Pech.
Marcus Lammerich
> Sascha Grage schrieb am Donnerstag 07 Januar 2010 14:35:
>
>> Pipelining kann man einschalten. Default ist aus.
>
> Das ist ja geil. Warum das denn?
>
> Und wie schaltet man es ein?
Seamonkey hat daf�r in den Eigenschaften unter Erweitert /
HTTP-Verbindung sogar checkboxen.
Vor einigen Jahren -dr�rfte so zu Mozilla Suite 1.7.x Zeiten gewesen
sein- war das Thema hier auch schon mal auf der Liste. Wie auch schon
hier erw�hnt, waren inkompatibilit�ten von Servern der Grund, warum es
nicht aktiviert ist. Inzwischen d�rften viele Server ja aktuellere
Software einsetzen. Kennt eigentlich jemand eine Server- /
Proxysoftware(version) die Probleme mit Piplining macht?
Seit damals habe ich die Option aktiviert und noch nie Probleme mit
einem Server gehabt, die ich auf Piplining zur�ckf�hren k�nnte.
Auf der anderen Seite merke ich aber auch keinen Unterschied.
Marcus
Peter J. Holzer
> Dietmar Hollenberg schrieb am Donnerstag 07 Januar 2010 16:34:
>> So jedenfalls zeigt der Firebug es in seinen Timelines
>
> Wie kommt man denn da ran?
https://addons.mozilla.org/en-US/firefox/addon/1843
hp
Andreas M. Kirchwitz
> Seamonkey hat dafür in den Eigenschaften unter Erweitert /
> HTTP-Verbindung sogar checkboxen.
Die gelten interessanterweise nicht für SSL (siehe about:config
und nach "pipe" suchen).
> Seit damals habe ich die Option aktiviert und noch nie Probleme mit
> einem Server gehabt, die ich auf Piplining zurückführen könnte.
> Auf der anderen Seite merke ich aber auch keinen Unterschied.
Mit Pipelining werden Webseiten gelegentlich inkorrekt geladen.
Nach einem Reload geht's wieder. Dem Gefühl nach würde ich die
Schuld nicht ausschließlich auf die Gegenseite schieben wollen,
sondern es scheint mir, leichte Netzwerk-Probleme begünstigen es,
dass der Webbrowser aus dem Tritt kommt.
So sehr ich Pipelining schätze, aber dem normalen User ist das
nicht zuzumuten. Und die Entwickler haben wohl auch keine Lust,
an der Robustheit dieses Features zu arbeiten, sondern setzen
angesichts heutiger Bandbreiten eher auf eine erhöhte Anzahl
gleichzeitiger Verbindungen.
Grüße, Andreas
Uwe Schröder
> Und die Entwickler haben wohl auch keine Lust,
> an der Robustheit dieses Features zu arbeiten, sondern setzen
> angesichts heutiger Bandbreiten eher auf eine erh�hte Anzahl
> gleichzeitiger Verbindungen.
Wobei das aber ein Scheinargument ist, denn die Bandbreite hat ja mit
der Anzahl der Verbindungen nichts zu tun. Eine 6-MBit-Leitung wird in
derr Summe weder schneller noch langsamer dadurch, da� ich die
Bandbreite auf 4 Verbindungen zu je 1.5 MBit aufteile, statt eine
Verbindung mit den vollen 6 MBit zu nutzen.
Im Gegenteil, hier verschluckt sich bei zu vielen gleichzeitigen
Verbindungen regelm��ig der Router, ich sch�tze mal, da� da die
NAT-Tabelle �berl�uft. :(
usch
Claus Reibenstein
> On 09.01.2010 02:11, Andreas M. Kirchwitz wrote:
>
>> Und die Entwickler haben wohl auch keine Lust,
>> an der Robustheit dieses Features zu arbeiten, sondern setzen
>> angesichts heutiger Bandbreiten eher auf eine erh�hte Anzahl
>> gleichzeitiger Verbindungen.
>
> Wobei das aber ein Scheinargument ist, denn die Bandbreite hat ja mit
> der Anzahl der Verbindungen nichts zu tun.
Das ist kein Scheinargument. Durch parallele �bertragungen kann die
Bandbreite besser ausgenutzt und der Durchsatz erh�ht werden, was in der
Praxis auch geschieht.
Du kannst ja mal einen Versuch machen: Suche Dir eine Seite mit vielen,
kleinen grafischen Elementen und lade diese Seite einmal mit nur einer
Verbindung und einmal mit mehreren parallelen, am besten bei
abgeschaltetem Cache.
> Eine 6-MBit-Leitung wird in
> derr Summe weder schneller noch langsamer dadurch, da� ich die
> Bandbreite auf 4 Verbindungen zu je 1.5 MBit aufteile
Das tut keiner. Das will auch keiner. Das w�re kontraproduktiv. Die
Bandbreite wird nach Bedarf dynamisch aufgeteilt.
> Im Gegenteil, hier verschluckt sich bei zu vielen gleichzeitigen
> Verbindungen regelm��ig der Router, ich sch�tze mal, da� da die
> NAT-Tabelle �berl�uft. :(
Das ist dann aber ein Problem des Routers und sollte mit dem Hersteller
desselben gekl�rt werden.
Gru�. Claus
Uwe Schröder
> Das ist kein Scheinargument. Durch parallele �bertragungen kann die
> Bandbreite besser ausgenutzt und der Durchsatz erh�ht werden, was in der
> Praxis auch geschieht.
Der Durchsatz erh�ht sich nicht aufgrund der Bandbreite, sondern
aufgrund der besseren Verteilung der Latenzen. W�hrend der Server auf
der einen Verbindung noch gr�belt, kann er auf der anderen schon Daten
�bertragen. Genau dasselbe soll Pipelining letztlich auch bewirken,
nur eben auf einer einzigen Verbindung.
Die Latenzzeiten sind von der Bandbreite v�llig unabh�ngig, weil sie
sich ja gerade dadurch auszeichnen, da� in dieser Zeit eben *keine*
Daten �bertragen werden.
> Du kannst ja mal einen Versuch machen: Suche Dir eine Seite mit vielen,
> kleinen grafischen Elementen
Damit vergr��erst du genau das Latenzproblem, siehe oben.
>> Eine 6-MBit-Leitung wird in
>> derr Summe weder schneller noch langsamer dadurch, da� ich die
>> Bandbreite auf 4 Verbindungen zu je 1.5 MBit aufteile
>
> Das tut keiner. Das will auch keiner. Das w�re kontraproduktiv. Die
> Bandbreite wird nach Bedarf dynamisch aufgeteilt.
Wenn der Server auf jeder Verbindung mit der maximal m�glichen
Datenrate sendet, ergibt sich das aber n�herungsweise automatisch.
Jedenfalls kann eine 6-MBit-Leitung in der Summe maximal 6 Mbit/s
�bertragen und eine 64-kBit-Verbindung maximal 64 kBit/s, egal ob auf
einer, auf vier, oder auf zehn Verbindungen. Insofern ist das Argument
Unsinn, "angesichts heutiger Bandbreiten" mehr Verbindungen *zu einem
Server* nutzen zu k�nnen als fr�her. Der Bandbreitenvorteil ergibt
sich erst bei mehreren Verbindungen zu *verschiedenen* Servern. In dem
Fall ist aber Pipelining eh kein Thema.
Au�erdem gilt meines Wissens immer noch RFC 2616 "A single-user client
SHOULD NOT maintain more than 2 connections with any server or proxy".
>> Im Gegenteil, hier verschluckt sich bei zu vielen gleichzeitigen
>> Verbindungen regelm��ig der Router, ich sch�tze mal, da� da die
>> NAT-Tabelle �berl�uft. :(
>
> Das ist dann aber ein Problem des Routers und sollte mit dem Hersteller
> desselben gekl�rt werden.
Nat�rlich, da kommt demn�chst ein anderer hin und fertig. Nur ist das
eben auch ein Problem, das keineswegs von der verf�gbaren Bandbreite
zum Uplink anh�ngig ist.
usch
Andreas M. Kirchwitz
>>> Und die Entwickler haben wohl auch keine Lust,
>>> an der Robustheit dieses Features zu arbeiten, sondern setzen
>>> angesichts heutiger Bandbreiten eher auf eine erhöhte Anzahl
>>> gleichzeitiger Verbindungen.
>>
>> Wobei das aber ein Scheinargument ist, denn die Bandbreite hat ja mit
>> der Anzahl der Verbindungen nichts zu tun.
>
> Das ist kein Scheinargument. Durch parallele Übertragungen kann die
> Bandbreite besser ausgenutzt und der Durchsatz erhöht werden, was in der
> Praxis auch geschieht.
Bei hoher Bandbreite schaffen es in der Tat manche Applikationen nicht,
diese mit nur einer einzigen Verbindung voll auszunutzen. Manchmal sind
auch Netzwerk-Geräte dazwischen verantwortlich, die ganz bewusst den
Durchsatz pro Einzelverbindung drosseln.
Mehrere Verbindungen sind ja durchaus hilfreich. Wenn dann aber
Firefox 3 oder SeaMonkey 2 diese von 8 auf 15 pro Server erhöhen,
stellt sich häufig der gegenteilige Effekt ein. Die Verbindungen
behindern sich gegenseitig. Es wird teilweise deutlich langsamer!
An dieser Stelle hilft Pipelining. Der Geschwindigkeitszuwachs beim
Seitenaufbau ist bemerkenswert, vor allem heutzutage bei Webseiten,
die aus sehr vielen kleinen Einzelobjekten bestehen.
Die Verbindungen pro Server immer weiter zu erhöhen, ist also dumm.
Sobald die Leitung voll ausgelastet ist (und dazu reichen meist
ein paar wenige Verbindungen), stehen die sich gegenseitig im Weg.
Der Server wird dadurch im übrigen auch nicht schneller, wenn sich
jeder Client immer gleich mit über einem Dutzend Verbindungen auf
ihn stürzt.
Funktionierendes Pipelining würde viel bringen, die existierende
Bandbreite noch besser zu nutzen.
Allerdings läuft Pipelining in der Praxis leider nicht rund.
Mit network.http.pipelining.maxrequests auf 8 (Maximum) stolpert man
leider häufig über Probleme. Mit maxrequests=4 (Default) kann man
halbwegs leben, aber für Anfänger ist's immer noch etwas verwirrend.
Mit maxrequests=2 ist mir bisher noch nie etwas Negatives aufgefallen,
allerdings ist der Gewinn leider nicht mehr so groß.
Schade eigentlich.
> Du kannst ja mal einen Versuch machen: Suche Dir eine Seite mit vielen,
> kleinen grafischen Elementen und lade diese Seite einmal mit nur einer
> Verbindung und einmal mit mehreren parallelen, am besten bei
> abgeschaltetem Cache.
Gerade in so einem Fall helfen mehrere Verbindungen nicht allein,
sondern hier kann auch Pipelining seine Stärken ausspielen.
Erst beides zusammen gibt optimale Performance.
Grüße, Andreas
Claus Reibenstein
> On 09.01.2010 12:17, Claus Reibenstein wrote:
>
>> Das ist kein Scheinargument. Durch parallele �bertragungen kann die
>> Bandbreite besser ausgenutzt und der Durchsatz erh�ht werden, was in der
>> Praxis auch geschieht.
>
> Der Durchsatz erh�ht sich nicht aufgrund der Bandbreite, sondern
> aufgrund der besseren Verteilung der Latenzen.
Danke, dass Du meine Aussage best�tigst. Aber wenn Du es eh schon wei�t:
Wieso behauptest Du dann erst das Gegenteil?
>> Du kannst ja mal einen Versuch machen: Suche Dir eine Seite mit vielen,
>> kleinen grafischen Elementen
>
> Damit vergr��erst du genau das Latenzproblem, siehe oben.
Genau darum ging es.
> Jedenfalls kann eine 6-MBit-Leitung in der Summe maximal 6 Mbit/s
> �bertragen und eine 64-kBit-Verbindung maximal 64 kBit/s, egal ob auf
> einer, auf vier, oder auf zehn Verbindungen. Insofern ist das Argument
> Unsinn, "angesichts heutiger Bandbreiten" mehr Verbindungen *zu einem
> Server* nutzen zu k�nnen als fr�her.
Nein, ist es nicht.
Du hast selber geschrieben, dass die Latenzzeiten von der Bandbreite
unabh�ngig sind. Genau deshalb wirken sie sich um so st�rker aus, je
schneller die Verbindung ist. Von daher ist es gar nicht so abwegig, bei
schnellen Verbindungen mehrere Kan�le parallel zu �ffnen.
Voraussetzung ist nat�rlich, dass der Server gen�gend Reserven hat, um
diese Verbindungen auch parallel zu bedienen. Ansonsten kann der Schuss
durchaus nach hinten losgehen.
> Der Bandbreitenvorteil ergibt
> sich erst bei mehreren Verbindungen zu *verschiedenen* Servern.
Nein. Er ergibt sich durchaus auch schon bei mehreren Verbindungen zu
_einem_ Server.
> Au�erdem gilt meines Wissens immer noch RFC 2616 "A single-user client
> SHOULD NOT maintain more than 2 connections with any server or proxy".
Lies den Satz mal im Zusammenhang des Absatzes: "Clients that use
persistent connections SHOULD limit the number of simultaneous
connections that they maintain to a given server. A single-user client
SHOULD NOT maintain more than 2 connections with any server or proxy".
Im �brigen ist der RFC bereits �ber 10 Jahre alt. Ob er noch g�ltig
und/oder sinnvoll ist, sei deshalb mal dahingestellt.
Gru�. Claus
Robert Kochem
> Wie kommst Du auf die Schnapsidee? Er _will_ ja alle Daten aus einer
> Quelle. Wenn die der Engpa� ist und nicht mehr rausr�ckt, ist das eben
> Pech.
Normalerweise verteilt die Quelle ihre Ressourcen gleichm��ig auf alle
Streams, die offen sind. Mehr Streams bedeuten dementsprechend auch mehr
Daten in gleicher Zeit.
Robert
Uwe Schröder
> Normalerweise verteilt die Quelle ihre Ressourcen gleichm��ig auf alle
> Streams, die offen sind. Mehr Streams bedeuten dementsprechend auch mehr
> Daten in gleicher Zeit.
Nur wenn du der einzige bist, der Bandbreitendiebstahl auf Kosten der
anderen Benutzer begeht. Wenn User A und User B beide jeweils eine
Verbindung aufbauen, bekommt jeder 50% der Bandbreite. Wenn User A
eine und User B zehn Verbindungen aufbaut, bekommt User B 91% der
Bandbreite auf Kosten von User A, der nur noch 9% bekommt. Wenn beide
zehn Verbindungen aufbauen, bekommt jeder wieder 50%. Also nichts
erreicht au�er zus�tzlichem Ressourcenverbrauch.
usch
Lothar Wiese
entschuldigt, dass ich hierzu eine off topic Frage stelle.
> Bei hoher Bandbreite schaffen es in der Tat manche Applikationen nicht,
> diese mit nur einer einzigen Verbindung voll auszunutzen. Manchmal sind
> auch Netzwerk-Geräte dazwischen verantwortlich, die ganz bewusst den
> Durchsatz pro Einzelverbindung drosseln.
>
> Mehrere Verbindungen sind ja durchaus hilfreich. Wenn dann aber
> Firefox 3 oder SeaMonkey 2 diese von 8 auf 15 pro Server erhöhen,
> stellt sich häufig der gegenteilige Effekt ein. Die Verbindungen
> behindern sich gegenseitig. Es wird teilweise deutlich langsamer!
In Google und d.c.o.m-w.misc konnte ich das Problem eines "Fehlers 2505
doppelter Netzwerkname ... \NetBT_Tcpip_... Serverdienst konnte nicht
gestartet werden", nicht lösen. Mein VPN könnte sich da wohl auch in
meinem Router oder dem Kabelmodem "verschlucken"? Liegt es vielleicht an
meinen vielen ständig in Firefox 3 geöffneten Tabs, die sich automatisch
updaten? Jedesmal bricht die Verbindung ab und VPN wählt neu.
Kennt so etwas jemand hier?
MfG
Lothar W.