Die Resultate des Lebensretter
Die so gerne angegebenen Requests pro Sekunde stellen
keine nützliche Größe dar. Kein Benutzer interessiert
sich dafür wieviele Seiten ein Server pro Sekunde ausliefern kann.
Reine Werbung: Requests pro Sekunde

X-Achse: Anzahl der gleichzeitigen Anfragen
Y-Achse: Requests pro Sekunde
Der einzig relevante Wert für den Internetznutzer ist
die Antwortszeit des Servers. Alles unterhalb einer Sekunde
fällt im Internet nicht auf, es fällt unter
den Verbindungsoverhead. Nach der ersten Sekunde
wird die Verzögerung spürbar. In der untenstehenden Grafik
ist die Antwortzeit (Requests / Requests/s) pro Request dargestellt.
Als grün wurden Zeiten um eine Sekunde bewertet, gelb bis drei Sekunden,
rot bis etwa fünf Sekunden. Darüber beginnt ein gefährlicher Bereich.
Bei mehr als fünf Sekunden droht der Reload-Button des Browsers
benutzt zu werden. Ist dies der Fall, wird der Server durch einen
weiteren, neuen Request belastet und die Antwortszeit steigt.
Bei der langen Antwortzeit ist auch mit vielen enttäuschten
Benutzern zu rechnen, die sich einem anderen Internetangebot zuwenden.
Der relevante Meßwert: Antwortzeit

X-Achse: Anzahl der gleichzeitigen Anfragen
Y-Achse: Wartezeit in Sekunden
Die Grafik macht klar, daß der Programmierer nachsitzen muß.
Der Consultant, welcher die Lösung verraten hat, sollte belohnt werden.
Ob die Hälfte der Preisdifferenz einer Sun Netra T1 ($ 5.000 - $ 10.000)
zu einer Sun Fire V880 ($ 30.000 - $ 120.000) unverschämt ist?
Ich denke nicht, schließlich hat er dafür gesorgt, daß nicht schon
bei 5 gleichzeitigen Zugriffen der Server spürbar langsam wird,
sondern es erst bei der 10 fachen Besucherzahl zu Engpässen kommt.
< ^ >
|