Hallo,
Ein Problem habe ich allerdings noch. Wenn ich mit meinem Browser z.b. die Startseite aufrufe und das mit F5 mehrmals sehr oft hintereinander, ...
hältst du das für eine aussagekräftige Testmethode?
Ich nehme an, du willst damit den Fall simulieren, dass mehrere Requests auf dieselbe Ressource innerhalb kurzer Zeit eingehen. Okay, dann kommt die Antwort eben mal etwas verzögert. Vergiss nicht, dass 25 Reloads ja nicht nur die 25 offensichtlichen Requests erzeugen, sondern für jeden Reload auch untergeordnete Requests für eingebundene Stylesheets, Bilder etc.
Im Prinzip müsste ja aber nur die letzte behandelt werden und der Rest könnte direkt gekillt werden, oder sehe ich das falsch?
Woher soll der Server wissen, dass einige der Requests für den Client schon nicht mehr interessant sind? Woher soll er wissen, dass es überhaupt immer derselbe Client ist[*]? HTTP bietet meines Wissens keine Möglichkeit, dem Server zu signalisieren: "Hör auf, hat sich erledigt". Ein Abbruch des Transfers kann AFAIK nur auf tieferer Protokollebene (Socket schließen und damit Verbindung beenden) realisiert werden. Aus Performancegründen wird ein Client aber eine bestehende Verbindung so lange offen halten, wie es nur geht, anstatt sie für jeden Request neu aufzubauen.
Das heißt aber, dass das Betriebssystem beim Client alle Requests, die der Browser anmeldet, schon in die Warteschlange einreiht und in Reih' und Glied an den Server übermittelt. Hinzu kommt, dass ein HTTP-Client normalerweise nur zwei Verbindungen zum selben Server *gleichzeitig* aufbaut, also auch eine parallele Verarbeitung der Requests nur bedingt stattfinden kann.
Ergo: Der Flaschenhals liegt bei deiner Testmethode vermutlich eher auf der Clientseite als beim Server.
So long,
Martin
[*] Es könnte ja auch sein, dass in einer Firma *zufällig* 25 Mitarbeiter mit gemeinsamem Internet-Zugang nahezu gleichzeitig dieselbe Seite abrufen.
Man sollte immer wissen was man sagt
- aber auf keinen Fall alles sagen, was man weiß.