Category Archives: Performance

Begriffe erklärt: Lasttest, Stresstest, …

Es gibt zahlreiche Begriffe für die verschiedenen Lasttest-Arten. Unsere Erfahrung aus der täglichen Arbeit, aus Gesprächen mit Kunden und aus der Auswertung von Suchwörtern zeigt, dass die Begriffe oft unklar sind und manchmal nicht ganz korrekt benutzt werden. Daher möchten wir hier unsere Sicht auf diese Begriffe darstellen.

  • Lasttest: Bei einem Lasttest wird die zukünftige Nutzung des zu testenden Systems unter Berücksichtigung bestimmter Benutzer- und Transaktionsmengen simuliert und bewertet. Dabei werden zwei grundsätzliche Ziele verfolgt. Das erste Ziel ist die Aufdeckung funktionaler Fehler, die nur unter paralleler oder intensiver Nutzung des Systems auftreten. Das zweite Ziel ist die Überprüfung des Zeit- und Verbrauchsverhaltens des getesteten Systems unter einer gegebenen Last. Dabei werden beispielsweise Antwortzeiten sowie der Verbrauch von Hauptspeicher und Rechenleistung ermittelt. Lasttests können auf unterschiedliche Aspekte eines Systems ausgerichtet sein. Dafür sind jeweils auch unterschiedliche Lastprofile und Testszenarien erforderlich, die oft mit eigenen Begriffen bezeichnet werden. Beispiele dafür sind “Skalierungstest”, “Stresstest” oder “Dauerlasttest”. Der Begriff “Lasttest” ist der Oberbegriff für alle diese Testarten.
  • Stresstest: Bei einem Stresstest wird die simulierte Last über das im Normalbetrieb erwartete Maß erhöht, bis funktionale Fehler auftreten oder das Antwortverhalten des getesteten Systems bestimmte Grenzen überschreitet. Hierfür wird oft eine kontinuierlich ansteigende Nutzerzahl simuliert. Stresstests verwendet man beispielsweise zur Ermittlung des Systemverhaltens in und nach Überlastsituationen, zur Ermittlung der maximal akzeptierbaren Last oder zum Finden von Performance-Schwachstellen (Bottlenecks). Continue reading Begriffe erklärt: Lasttest, Stresstest, …

Xceptance LoadTest 3.3 ist verfügbar

Ab sofort steht das Softwarepaket Xceptance LoadTest (XLT) 3.3 zum kostenlosen Download bereit.

Dahinter verbirgt sich schon die erste Neuerung, denn mit dem Download besitzt man automatisch eine freie Basislizenz. Sie erlaubt Tests mit bis zu fünf virtuellen Nutzern, gilt zeitlich unbegrenzt und unterliegt keinen Nutzungseinschränkungen. Damit darf man XLT auch kommerziell einsetzen, beispielsweise intern oder in Kundenprojekten. So kann man ungehindert prüfen, ob XLT das Werkzeug der Wahl ist oder man kann XLT bereits produktiv für Regressionstests verwenden.

XLT 3.3 bietet einige neue Features, die die tägliche Arbeit effizienter gestalten und den Einsatzbereich von XLT erweitern:

  • Comparison-Reports zum detaillierten Vergleich zweier Testläufe
  • Trend-Reports zur Visualisierung von Veränderungen in den Testergebnissen über mehrere Testläufe hinweg
  • Unterstützung des Google WebDriver API für schnelles Prototyping von Testfällen
  • Ruby als zusätzliche Scriptsprache zur Testfallerstellung
  • Programmierbeispiele für typische Anwendungsfälle, zum Beispiel für die Bearbeitung von Ajax-Requests und die Behandlung von Popups oder Frames
  • Überarbeiteter Testrecorder mit der Unterstützung für Voreinstellungen zur Codegenerierung

Zusätzlich sind wieder viele Detailverbesserungen in diese Version eingeflossen. Weiterführende Informationen gibt es in den Releasenotes oder auf den Produktseiten unseres Webauftritts.

Vergleich von Lasttest-Ergebnissen

Übersicht über die Unterschiede in der Request-LaufzeitDie kommende Version von XLT (3.3) wird ein schönes neues Feature mitbringen: Die Möglichkeit des Vergleichs von Lasttest-Ergebnissen und die dazu gehörige Visualisierung. Hier nur ein kleiner Ausschnitt aus einem Report. So oder so ähnlich wird es dann aussehen.

Wie gewohnt, wird auch der Vergleich von Lasttest-Ergebnissen nur mit offenen Datenformaten arbeiten. Außerdem wird der Vergleich basierend auf den bereits existierenden Reports erstellt. Damit kann man schnell und einfach zwei Reports vergleichen und sich ein Bild von den Fortschritten oder aktuellen Problemen machen.

Alle Kunden, die bereits XLT einsetzen, sind herzlich zu einem Vorabtest der Entwicklungsversion 3.3 eingeladen.

Unterschied zwischen Visits und Pageviews

Heute habe ich eine Suchanfrage zum Thema “Unterschied zw Visits und Pageviews” entdeckt. Da wir leider keine passende Antwort im Blog haben, soll es jetzt glatt eine geben. Kunde ist schließlich König. Hier nun als die Erklärung.

Was ist ein Visit?

Ein Visit ist der Besuch eines Kunden auf einer Webseite. Dabei gilt, dass der letzte Besuch bereits einige Zeit her sein muss, damit dieser neue Besuch als neuer Besuch gilt. Im Ecommerce wird häufig der Begriff Session/Sitzung verwendet. Dieser Begriff ist auch technisch geprägt, denn der Server besitzt interne Strukturen, die Details über den Besuch für eine gewisse Zeit speichern.

Ein Visit entsteht, wenn der Nutzer einen Request an einen Server schickt und als Antwort eine Webseite angezeigt bekommt. Die Anzeige der Webseite ist übrigens der Pageview, dazu aber später mehr. Ein Visit hat mindestens einen Pageview, typischerweise aber mehrere. Zeitlich zusammenhängende Pageviews eines Nutzers bilden damit einen Visit.

Als Beispiel sei einfach mal ein Besuch bei Amazon genannt. Man tippt www.amazon.de ein, bekommt eine Webseite angezeigt und schwupst hat man einen Visit erzeugt. Jetzt bewegt man sich durch den Shop und alles was man macht, fällt unter diesen einen Visits.

Sollte man eine gewisse Zeit nichts machen, also seinen Browser geschlossen haben oder einfach nicht klicken, dann beendet sich der Visit, denn auf der Serverseite werden die Informationen über den Besuch entfernt bzw. inaktiv gesetzt. Abhängig vom Webangebot ist ein  Zeitraum von 30 Minuten bis 24 Stunden möglich.

Wichtige Messgrößen sind die Länge eines Visits (Visit Duration), die Anzahl der Pageviews und der Abstand zwischen zwei Pageviews (Thinktime).

Andere Begriffe für Visits sind: Besuch, Besucher oder Session.

Was ist ein Pageview?

Ein Pageview stellt die Anzeige einer Webseite dar. Ich schicke also einen Request/Anfrage an einen Webserver und bekomme als Antwort eine Webseite, da ich sie sehe, ist das dann der Pageview.

Noch vor kurzer Zeit war für einen Pageview nur ein Request an den Server nötig, der mir eine Webseite lieferte. Mit weiteren Request hat dann der Browser Bilder, CSS und Javascript ergänzt und mir die Seite gezeigt. In der modernen Webwelt ist die Definition Pageview etwas weicher und ungenauer, denn AJAX und moderne Nutzerkonzepte tauschen keine kompletten Webseiten mehr aus, sondern ändern oft nur kleine Teile. Damit haben wir keinen Pageview mehr, sondern nur noch eine Interaction oder eine Action.

Bleiben wir aber einfach mal beim altmodischen Pageview. Ein Pageview wird durch einen Request (technisch) eingeleitet und durch die Antwort (Response) des Servers beendet. Diese Abfolge wird oft auch als Hit bezeichnet. Ein Seite kann nun andere Elemente beinhalten, zum Beispiel Bilder und CSS. Jedes dieser Elemente wird nun wieder mit Request/Response abgewickelt und formt wiederum einen weiteren Hit.

Ein Pageview besteht also aus einem HTML-Teil und vielen eingebetteten Elementen. Jede Komponente und der HTML-Teil verursachen jeweils einen Hit.

Wichtige Messgrößen sind zum Beispiel: Ladezeit der Page, Größe der Seite und Länge der Betrachtung, also die Zeit bis zum nächsten Klick.

Andere Begriffe für Pageview sind: Page Impression, Page Hit und Seitenaufruf.

Fazit

Ein Visit besteht also aus einem oder mehreren Pageviews und hat eine Dauer. Ein Pageview dagegen hat eine Laufzeit und besteht aus Elementen, die selbst als Request oder Hit bezeichnet werden.

Verwirrt? Macht nichts. Einfach in den Kommentaren fragen. Außerdem ist die Begrifflichkeit nicht fest definiert und wird oft leicht anderes verwendet.

Read about visits, page views, sessions and requests in English:

https://blog.xceptance.com/2013/05/14/terms-explained-visits-page-views-sessions-requests-hits/

Parallele Nutzer – die Kunst der Berechnung

Die Meisten dürften den Begriff Parallele Nutzer (Concurrent User) kennen. Im Bereich des Last- und Performancetests wird die Zahl Parallele Nutzer gern als Maß aller Dinge herangezogen. Dabei tauchen gern astronomische Zahlen auf, die beim genauen Hinsehen oft überhaupt nicht überprüfbar sind. Leider sind diese Zahlen oft auch ein Verkaufsargument für völlig überpreiste Software.

Mit diesem Blogeintrag möchte ich gern einige Mythen und Missverständnisse aufklären und Licht in die Welt der Parallelen Nutzer bringen. Meinungen, Einwände und natürlich auch Zustimmung dürfen gern als Kommentar verewigt werden.

Fangen wir mit einigen Grundbegriffen an, damit wir alles über das Gleiche reden. Da wir uns als Firma meist in den Bereichen Internet und Ecommerce bewegen, sind natürlich Beispiele auf Webshops bezogen. Das Thema ist natürlich nicht auf Ecommerce-Lasttests beschränkt.

Die Begriffe

  • Visit: Als Visit wird ein zusammenhängender Besuch einer Webpräsenz bezeichnet. Der Visit hat eine Dauer (erstes Byte, erster Request bis letztes Byte, letzter Request). Ein Besuch besteht aus einem oder mehreren Pageviews. Zwischen den einzelnen Pageviews liegt die Denkzeit (Thinktime).
  • Session: Technischer Begriff oder technische Repräsentation eines Visits. Oft werden Visit und Session als Synonyme benutzt.
  • Pageview: Der Aufruf einer URL oder Webseite (auch Page-Impression). Ein Pageview kann eine Vielzahl mehrerer technischer Requests nach sich ziehen (Html, CSS, Javascript, Bilder etc.), aber besteht immer mindestens aus einem Request.
  • Request: Anfrage an einen Server, im Falle von Webapplikationen in den meisten Fällen unter Nutzung der Protokolle HTTP/HTTPS. Der zurückgelieferte Inhalt kann HTML, CSS oder Javascript sein, es können Bilder oder Videos, Flash oder Silverlight Applikationen ausgeliefert werden. Über HTTP lässt sich fast alles transportieren.
  • Thinktime/Denkzeit: Abstand zwischen zwei Pageviews innerhalb eines Visits.
  • Szenario: Ablauf eines Visits im Sinne eines Usecases (zum Beispiel Suchen oder Bestellen oder auch beides). Szenarien repräsentieren oft abgebildete Testfälle, die als Lasttest ausgeführt werden sollen.
  • Parallele Nutzer: So genau wissen wir das jetzt noch nicht…

Der Last- und Performancetest

Ein Lasttest bildet die existierende Realität ab oder will eine Zukunftserwartung widerspiegeln. In beiden Fällen ist es nicht möglich, mit vertretbarem Aufwand alle Möglichkeiten abzudecken, sie sich ergeben oder vorstellbar sind. Die Wege durch einen Webshop sind vielfältig und eigentlich gibt es eine unendliche Anzahl davon. Aus diesem Grund wählt man zuerst die typischsten Testcases aus und formt diese in Szenarien um. Im Falle eines Szenarios wird in den meisten Fällen nur davon ausgegangen, dass es sich um einen isolierten Visit handelt, der die Vorgänge des Testcases wiederholt und damit definierte (auch zufällige Daten sind definiert) nutzt.

Als Beispiel nehmen wir drei Szenarien: Ein Besucher, der sich nur umschaut (Browsing); ein Besucher, der interessante Produkte in den Warenkorb legt (Add2Cart) und einen Besteller, der seinen zusammengestellten Warenkorb auch nach Hause geliefert bekommen möchte (Order). Für unser Beispiel registriert sich der Nutzer nicht, er kauft also anonym ein bzw. ohne Nutzung einer Registrierung.

Die Nutzer müssen alle Grundschritte durchführen, um ihrem Szenario gerecht zu werden:

Browsing-User

  1. Homepage
  2. Auswahl eines Kataloges
  3. Auswahl eines Unterkataloges
  4. Auswahl eines Produktes

Add2Cart

  1. Browsing 1.-4.
  2. Produkt in den Warenkorb legen

Order

  1. Add2Cart 1.-2.
  2. Checkout beginnen
  3. Adressen eingeben
  4. Zahlungsmethode wählen
  5. Lieferart wählen
  6. Bestellung bestätigen

Die erste Herausforderung besteht in der Wahl der Inhalte für die einzelnen Aktionen. Soll es immer das gleich Produkt sein, immer die gleichen Katalog, sollen Mengen variiert werden, Warenkorbgrössen usw… Allein diese drei Szenarien bieten sich unendliche Variationsmöglichkeiten. Aber bleiben wir zunächst bei den Grundschritten und einfach nur beim einfachen Browsing.

Die Parallelen Nutzer

Die einmalige Ausführung eines Browsing wäre im Rahmen eines Tests gegen den Server ein Visit, bestehend aus 4 Pageviews, mit ggf. weiteren Requests für statische Inhalte. Wird der Test zweimal ausgeführt und alle Daten und Verbindungen (Cookies, HTTP-Keep-Alive, Browsercache) zurückgesetzt, so ergibt sich ein weiterer Visit. Führt man diese beiden Visits jetzt unabhängig parallel aus, dann ergeben sich zwei parallele Nutzer, wobei Nutzer hier umgangssprachlich zu verstehen ist, eigentlich sind es parallele Visits. Ich selbst bevorzuge den Begriff Visits.

Unsere beiden Visits führen nun jeweils vier Pageviews aus. Macht also insgesamt 8. Da jeder Pageview eine Grundlaufzeit im Server hat, sagen wir 1 Sekunde, dauert also ein Visit mindestens 4 Sekunden. D.h. wenn ein Nutzer seine Visits eine Stunde lang wiederholen würde, dann hätte er 3.600 Sekunden / 4 Sekunden pro Visit = 900 Visits absolviert. Zwei Nutzer gleichzeitig also 1.800 Visits, insgesamt dann 1.800 Visits x 4 Pageviews pro Visit = 7.200 Pageviews.

Die Denkzeiten

Nun sind natürlich die wenigstens Nutzer so zügig unterwegs und deswegen werden oft Denkzeiten/Thinktimes eingerechnet. Die durchschnittliche Denkzeit dürfte momentan im Schnitt (je nach Webauftritt natürlich) bei ca. 10-20 Sekunden liegen. Früher waren es eher 40 Sekunden, aber die Anwender haben inzwischen mehr Erfahrung, wissen mehr und die Nutzerführung hat sich auch verbessert, so dass man schneller im Webangebot navigieren kann. Für unsere Berechnung nehmen wir einfach 15 Sekunden Denkzeit an.

Ein Visit würde jetzt also 4 Pageviews a 1 Sekunde plus 3 Denkzeiten a 15 Sekunden dauern. Nach dem letzten Klick gibt es keine Denkzeit, der Visit ist beendet, deswegen nur 3×15 und nicht 4×15. Insgesamt dauert unser Visit also jetzt 49 Sekunden. Würden wir jetzt also wieder einen Nutzer eine Stunde klicken lassen und jeweils 4 Pageviews als Visit definieren, inkl. der Denkzeit, so kann ein Nutzer 3.600 Sekunden / 49 Sekunden pro Visit = 73,5 Visits pro Stunde absolvieren.

Möchten wir jetzt wieder 1.800 Visits testen, so benötigen wir 1800 Visits / 73,5 Visits pro Stunde pro Nutzer = 24,5 Nutzer, also rund 25. Die Anzahl der Pageviews bleibt gleich, da ja ein Visit vier Pageviews sind und die Anzahl der Visits konstant ist.

Diese 25 Nutzer müssen jetzt also parallel und gleichzeitig, trotzdem unabhängig voneinander ihre Besuche vollziehen.

Der Zufall und die Varianz

Wir haben also nun 25 parallele Nutzer, die exakt den gleichen Simulationstraffic erzeugen, wie 2 Nutzer ohne Denkzeit. Exakt den gleichen Datenverkehr? Nein, natürlich nicht, denn jetzt kommt extreme Parallelität und die Unvorhersagbarkeit von Tests und ja auch der Realität ins Spiel.

Würde unsere Anforderung heissen, dass wir 1.800 Visits pro Stunde simulieren sollen und 7.200 Pageviews pro Stunde, so könnten wir jetzt die Denkzeit beliebig schieben und eine Zahl zwischen 2 und X Simulationsnutzern wählen.

Wo liegt nun der Unterschied zwischen 25 Nutzern und 2 Nutzern? Für unsere Simulationsperiode von einer Stunde heisst es für den Server, dass er aller 2 Sekunden, eine neue Session (Visit-Beginn) sieht – 3600 Sekunden / 1800 Visits. Schliesslich sind unsere Visits gleichverteilt

Achso, wären unsere Visits nicht gleichverteilt, dann würden wir nicht 1800 Visits, sondern viel mehr simulieren. Warum? Nehmen wir an, es heisst, wir werden 1800 Visits per Stunde haben, aber 100 Nutzer gleichzeitig. Nun wissen wir aus unsere Berechnung, dass ein Visit 49 Sekunden dauert. Sind 100 Nutzer gleichzeitig aktiv, so würde der Server pro Stunde 3600 / 49 * 100 = 7.347 Visits sehen. Unsere Simulation muss etwas annehmen und das ist immer der schlimmste Fall. Auch brauchen wir einen handhabbaren Zeitraum, eine Sekunde ist etwas zu fein. Eine Stunde ist immer sehr günstig, da die meisten Internetstatistiken immer auf eine Stunde hoch- oder runtergerechnet werden können.

Man kann aber auch anderes herangehen, um die Zahlen zu hinterfragen bzw. anders zu betrachten. Wenn 100 Nutzer gleichzeitig aktiv sind, dann können sie 100 Pageviews gleichzeitig anfordern. Im schlimmsten Fall wären das aber (ein Pageview braucht 1 Sekunde auf dem Server) dann 100 * 3600 Sekunden = 36.000 Pageviews pro Stunde. Weil die Aussagen 100 parallele Nutzer eigentlich nie an einen Zeitraum gebunden ist, muss man also annehmen, dass zu jedem Zeitpunkt diese Nutzer theoretisch klicken könnten.

Damit sieht man schnell, dass die Zahl der Parallelen Nutzer für sich allein gesehen nur im Raum schwebt und alles sein kann. Viel Traffic, wenig Traffic, wenig Last, viel Last. Nur mit der Kenntnis der Testfälle und der weiteren Zahlen, wie Visits und Pageviews pro Zeiteinheit, lässt sich a) eine Anzahl von Parallelen Nutzern ermitteln und b) jede der Zahlen mit Hilfe von Berechnungen gegen die anderen Zahlen überprüfen.

Nicht zu vergessen, dass 42 immer eine gute Anzahl an Parallelen Nutzern ist…

Warum 100.000 Nutzer nicht 100.000 Visits sind

Was ich damit ausdrücken möchte, ist die unbedingte Notwendigkeit einer zeitlichen Dimension. Die Vorgabe 300.000 Nutzer würde immer heissen, sie könnten gleichzeitig klicken. Wir hätten also mit einem Schlag 300.000 Visits eröffnet. Das Argument heisst jetzt bestimmt, aber sie kommen ja nicht gleichzeitig. Sind die Nutzer aber nicht gleichzeitig mit einem Visit aktiv, dann sind es keine Parallelen Nutzer und man braucht sie auch nicht simulieren.

300.000 Nutzer pro Stunde, die glaube ich mit Visits in den meisten Fällen gleichgesetzt werden, würden also mit der Annahme einer Gleichverteilung und einer durchschnittlichen Visitdauer von 49 Sekunden zum Einsatz von (jeder Nutzer schafft pro Stunde 3600 / 49 = 73,5 Visits) 300.000 / 73,5 = 4081 Parallelen Nutzern führen. 4081 Nutzer machen in 49 Sekunden (Visitlänge) jeder 4 Pageviews, d.h. in 49 Sekunden haben wir 16.324 Pageviews, pro Sekunde sind das also 333 Pageviews (siehe nächster Paragraf).

Oder denken wir einfach nur in Pageviews ohne Denkzeit. 300.000 Nutzer sind 1.200.000 Pageviews (für unser obiges Beispiel). Also muss ich 1.200.000 / 3600 = 333 Pageviews pro Sekunde ausführen. Ohne Denkzeit würde ich also 333 Nutzer zur Simulation benötigen. Jeder schafft 3600 / 4 Pageviews = 900 Visits pro Stunden, also haben wir am Ende 299.700 Visits ausgeführt (etwas Rechenunschärfe ist dabei, gut gerundet halt).

Für das Endergebnis ist also genau genommen die Simulation mit 4081 Nutzern und 15 Sekunden Denkzeit oder 333 Nutzern ohne Denkzeit identisch. Der Server sieht die gleiche Anzahl von Visits pro Zeitperiode, die gleiche Anzahl an Pageviews etc.

Das kann doch nicht sein

Mit Recht werden jetzt Einwände laut und diese sind berechtigt, denn in der Realität würde die Denkzeit nie exakt 15 Sekunden betragen und auch nie die Antwortzeit immer 1 Sekunde. Hier kommt der Zufall ins Spiel. Für unser Beispiel nehmen wir an, dass die Denkzeit zwischen 10 und 20 Sekunden schwankt. Das Mittel wären immer noch 15 Sekunden.

Was jetzt passiert, wirkt sich rechnerisch so aus. Im schlimmsten Fall, sind jetzt alle Visits nur noch 4 Sekunden + 3 x 10 Sekunden lang, also 34 Sekunden. Das bedeutet, dass unser Server innerhalb von 34 Sekunden jetzt die Anzahl der Visits und Pageviews liefern muss, die bisher in 49 Sekunden ausgeliefert wurden. In diesem Moment würde der Tests also nicht 300.000 Nutzer mit 4081 parallelen Testnutzern abdecken, sondern 3600/34*4081 = 432,105 Visits pro Stunde.

Das heisst, man muss sich auf Zielzahlen festlegen, die man unterstützen möchte bzw. messen, was der Server momentan liefern kann. Sobald man sagt, man hat X Visits, aber die könnten in der Länge schwanken, hat man wieder eine höhere Maximalzahl an Visits geschaffen, die man unterstützen muss, aber eigentlich nicht testen will.

Das wäre der reine Blick auf den Last- und Performancetest. Wir möchten also wissen, ob wir dem Ansturm X gewachsen sind. Wobei X theoretisch (und so ist es im Test), beständig für einen längere Zeitperiode als schlimmster Fall (Worst-Case) gilt. Möchte man den Server jenseits des maximalen “guten” Falles ausmessen, dann jagt man nicht mehr Performance, sondern erforscht das Überlastverhalten. Hier legt man Wert auf Stabilität und eine vorhersagbare Art- und Weise der “Verschlechterung”. Alle Tests, die normalerweise zuerst gemacht werden, und das ist richtig so, sind Tests, die den Gutzustand ermitteln oder beweisen wollen.

Und doch….

Selbstverständlich kann es Sinn machen, mit 4081 statt 333 Nutzern zu testen, auch wenn der Server die gleiche Anzahl von Visits und Pageviews pro Zeitperiode sieht. 4081 Nutzer können halt sehr kurz parallel erscheinen und damit zum Beispiel 4081 Webserver-Threads oder Sockets beanspruchen, während 333 Nutzer nie auf diese Zahl kommen werden. Selbst wenn man die Denkzeit bei den 4081 Nutzer konstant hält, wird durch die variablen Antwortzeiten der Traffic nicht mehr so synchron laufen, wie er am Start geplant war.

Im schlimmsten Fall kann das dazu führen, dass wir so überhaupt nicht testen können, weil jeder Durchlauf ein anderen Ergebnis liefert. Durch die Reduktion auf 333 Nutzer mit keiner oder minimaler Denkzeit schränken wir zunächst die “Bewegung” des Systems ein, um es vermessen zu können. Wenn das System liefert, was es soll, dann kann der Test in die Breite wachsen.

Steady Load versus Constant Arrival Rate

Um das Dilemma zu lösen, ohne a) auf den Server Rücksicht zu nehmen und b) trotzdem vernünftig messen zu können, kann man aus zwei typischen Lastprofilen wählen.

  • Steady Load: Hier wird eine fixe Anzahl von Nutzer losgeschickt, die auch auf den Server warten, wenn der Server z.B. lange Antwortzeiten hat und so wird das Visitziel nicht erreicht, weil die Nutzer vom Antwortverhalten des Servers abhängen. Das Verfahren ist aber günstig für kontrollierte Messungen, da man Schwankungen unterbindet.
  • Constant Arrival Rate: Hier kommen die Nutzer (arrival rate) als neue Besucher unabhängig vom Serverzustand an. Auch wenn der Server klemmt, werden neue Nutzer es trotzdem versuchen. Wenn der Server mit der Last umgehen kann, dann schwingt sich das System/der Regelkreis ein – man braucht eine Nutzeranzahl X (entsprechend der Berechnung z.B. 4081). Sollte der Server Probleme haben, dann erhöht sich die Nutzeranzahl automatisch bis zu einem Wert X + n (z.B. insgesamt 10.000 Nutzer). Das heisst, man braucht im besten Fall nur 4081 Nutzer, aber wenn der Server sich unerwartet verhält, werden bis zu 10.000 Nutzern aktiviert. Damit testet man auch gleich das Überlastverhalten.

Der Schluß

Ich hoffe, der Text ist einigermaßen verständlich und der Zahlenwust ist überschaubar geblieben. Das Thema Parallele Nutzer (Concurrent User) nimmt teilweise schon religöse Züge an…

Anmerkungen sind sehr willkommen.

Webseiten schneller machen – Teil 1

Photo by 96dpi

Wenn man über Webseiten-Performance spricht, dann denken die Meisten sofort an die Leistung des Servers bei der Auslieferung der Inhalte. Das ist im Prinzip auch nicht falsch, aber nur die halbe Wahrheit. Natürlich kann man eine Seite nicht schneller anzeigen, als sie ausgeliefert wird, so dass eine gute Leistung des Servers Grundvoraussetzung ist, aber es geht halt ohne grosse Anstrengungen langsamer.

Wie? Langsamer?

Moderne Webseiten bestehen aus vier Hauptkomponenten: Html, CSS, Javascript und statischen Inhalten, wie zum Beispiel Bildern und Flash. Die endgültige Webseite kommt nur im Browser zu Stande, wenn alle diese Einzelteile zusammengefügt wurden. Diese finale Schritt wird als Rendern bezeichnet.

Jede Einzelkomponente muss über das Netz geladen werden und die Komponenten werden in einer gewissen Reihenfolge geladen. So ist zum Beispiel immer zuerst die HTML-Hauptseite dran, dann Frames, dann CSS und Javascript aus dem Header, dann Bilder, dann anderer Content und irgendwo mittendrin wird noch das Javascript ausgeführt (denn Laden und Ausführen sind nicht das Gleiche). Um es kompliziert zu machen, macht es jeder Browser etwas anders.

Sollte ein Teil klemmen bzw. langsam sein, so können oder werden nachfolgende Teile nicht geladen und die Seite nicht bzw. unvollständig angezeigt. Oft fällt das beim Spiegel-Online, Welt-Online oder ähnlichen Angeboten auf, denn dort sieht man oft nur den Header und dann kommt einen Moment nichts… oder mehrere Momente nichts und endlich macht es Pling.

Da ich hier nicht alle Teile aus dem Yahoo-Performance-Guide kopieren möchte, wie man das Pling vermeiden kann und wie alles viel schneller geht, hier noch etwas erklärende Theorie für das Grundverständnis. Hier meine Favoriten und die bildliche Erklärung. Zuerst sei noch ein Missverständnis erklärt.

Meine Kunden haben doch Breitband, wo ist das Problem?

Breitband ist schön, Breitband ist toll, aber ein LKW mit Ladung ist auf einer 10-spurigen Autobahn nur unwesentlich schneller als auf den traditionellen zwei Spuren. Warum? Wenn ich Ware nach von A nach B bringe, dann muss ich den LKW be- und entladen, sowie der LKW muss auf die Autobahn auf- und abfahren. Egal wie breit die Autobahn dazwischen ist, diese Grundschritte sind immer dabei und immer gleich schnell. Eventuell haben wir nur weniger Stau unterwegs bzw. ich kann vier LKWs schicken, statt einem… sofern ich etwas zu transportieren habe und sich die LKWs nicht am Verladezentrum stauen.

Genauso verhält es sich mit Anfragen an einen Webserver. Das Datenpaket wird gepackt, versendet und ausgepackt, danach beantwortet, die Anfrage eingepackt, versandt und wieder ausgepackt. Nur die beiden Versandschritte gehen schneller mit einer dicken Leitung, der Rest bleibt.

Und wo ist nun das Problem?

Ja, ich habe es immer noch nicht richtig verraten, aber das Problem der meisten Webseiten ist, dass sie aus vielen vielen Einzelteilen zusammengesetzt werden und je mehr Teile es sind und je mehr Teile von unterschiedlichen Servern stammen, desto langsamer wird die Sache.

Das führt zum lustigen Effekt, dass das Laden von 5 Bildern a 50kB schneller geht, als das Laden von 10 Bildern a 15kB, obwohl die Gesamtgrösse der 10 Bilder deutlich geringer ist. Leider führen 10 Bilder zum Zweifachen Overhead im HTTP-Protokoll, in der DNS-Auflösung, in der Bestimmung der Serverantwort und und und.

Regel Nummer 1 heisst deswegen – Weniger HTTP-Anfragen

Diese Regel ist die absolut goldene Regel und lässt sich durch das Zusammenlegen von Einzel-CSS in ein CSS-File erreichen, durch das Zusammenführen von Javascript-Dateien und statt den Seiten-Header in 8 Bilder zu zerlegen, schickt man lieber nur 2 Bilder.

Man darf dabei auch nicht aus den Augen verlieren, dass diese Inhalte auch gecacht werden sollten, damit der Browser beim Weiterklicken nicht nochmal alles von vorn alles laden muss. Hier ist also zwischen Zerlegung, Grösse, und Wiederverwendung abzuwägen.

Regel 8 – Javascript und CSS gehören in Einzeldateien

Man sollte niemals CSS und Javascript in grossen Mengen in das HTML einbetten. Dieser Teile gehören extern und so aufbereitet, dass sie wiederverwendbar sind. Das macht die Pflege einfacher und die eigentlichen HTML-Seiten kleiner.

Regel 19 – Die Anzahl der DOM-Elemente reduzieren

Was der Browser nicht lesen muss, dass kostet keine Zeit und keinen Speicher. Jedes HTML-Element und vor allem jede Zeile Javascript-Code muss interpretiert und verwaltet werden. Damit ist eigentlich schon einleuchtend, dass der HTML-Code sauber und einfach strukturiert sein sollte.

Als Beispiel lässt sich bei

locker das span einsparen, denn a ist bereits ein Inline-Element und span fügt hier keine Struktur hinzu. Das ist aus der Praxis, das habe ich mir nicht gerade ausgedacht.

So, dass war eigentlich schon recht viel für den Anfang und deswegen gibt es demnächst mehr zu den anderen Tipps von Yahoo. Wer es eilig hat, der kann auch direkt nachlesen: Best Practices for Speeding Up Your Web Site.

Photo by 96dpi under CC-BY-2.0