Wer sagt denn, dass man als Tester nicht kreativ sein kann. Dieses Meisterwerk ist mir heute bei einem Lasttest geglückt. Ich nenne es Himalaya.

Das soll mir Bob Ross erstmal nachmachen.

Wenn wir mit Kunden über die möglichen Lasttesteckdaten sprechen, dann ist immer wieder von Visits und Sessions die Rede. Beide Begriffe stammen aus dem Englischen, sind aber durch das Internet und die meist in Englisch ablaufende Softwareentwicklung in den allgemeinen Sprachgebrauch im Bereich Last- und Performancetests eingegangen. Selbstverständlich gibt es auch deutsche Entsprechungen, wenn auch weniger oft benutzt: Besuche und Sitzungen.

Warum geht es im Allgemeinen?

Visits und Sessions sind Begriffe aus der Webentwicklung, werden aber auch als Metriken im Webumfeld genutzt. Der technische Teil verbindet sich in der endgültigen Definition mit der wirtschaftlich/mathematischen zur eigentliche Bedeutung. Was wir also wollen ist: a) wissen was dahinter steckt, b) erfahren was die Begriffe definieren und c) wissen wozu man die Zahlen braucht.

Was ist ein Visit?

Wenn man sich dazu entschließt, eine Webseite zu besuchen, dann ruft man irgendwann eine erste Seite auf. In diesem Moment hat man einen Visit begonnen oder auf Deutsch – man ist zum Besucher geworden. So lange man sein Surfen auf dieser Webseite fortsetzt, solange setzt man seinen Visit fort. Alle einzelnen Seiten zusammengenommen, bilden damit, beginnnend mit der ersten Seite, einen Visit.

Für den Betreiber ist damit klar, dass ein Interessent oder Kunde seiner Webseite einen Besuch abgestattet hat. Am besten läßt sich das mit dem Besuch eines realen Ladens vergleichen. Wenn man in den Laden geht, dann beginnt man seinen Besuch/Visit und wenn man ihn wieder verlässt, dann endet der Besuch/Visit.

Natürlich gibt es auch Ausnahmen von der Regel. Wenn man nur mal schnell 5 Minuten in die Küche geht bzw. in einem realen Laden schnell zum Auto läuft, weil man sein Geld vergessen hat, dann zählt das nur als ein Visit, weil man nur eine Besuchsabsicht hatte.

Über die Metrik Visit läßt sich damit einfach messen, wieviele Besuchsabsichten pro Zeiteinheit vorgelegen haben und auch in die Tat umgesetzt wurden. Dabei spielt es keine Rolle, ob man etwas kauft, zurückbringt oder gleich wieder an der Tür kehrt macht.

Im Internet gibt es nicht nur echte Besucher, sondern auch jede Menge Automaten, die sich in den Netzweiten herumtreiben und mit jedem Abruf einer oder mehrerer Seite jeweils auch einen Visit erzeugen. Das bringt natürlich die Statistiken durcheinander. Deshalb versucht man durch technische Maßnahmen, diese meist unrelevanten Besuche herauszurechnen. Das Wie kann bei Interesse ein weiterer Blogeintrag werden.

Was ist eine Session?

Nun haben wir geklärt, was hinter dem Begriff Visit steckt, aber was ist dann eine Session?

Einfach gesagt, ist eine Session die technische Abbildung eines Besuchs/Visit. Die genutzte Technik und Software müssen sich nämlich merken, welche Anfragen zusammengehören, damit es möglich wird, Dinge wie ein Login oder einen Warenkorb technisch umzusetzen.

Sessions bestehen aus Daten, die Informationen über die Vorgänge des Visits zusammenfassen, oft als Sessioninformationen bezeichnet. Diese Datensätze haben im Regelfall eine begrenzte Lebenszeit. Wenn man seinen Visit beendet bzw. nicht fortsetzt, also nicht mehr klickt, dann beginnt eine Uhr zu ticken, die nach eine einstellbaren Zeit (oft 30 Minuten bis 2 Stunden), die Daten entfernt, damit es zu keinen Überläufen kommt. Das nennt sich Session-Timeout. Nimmt man vor Ablauf der Zeit seinen Besuch wieder auf, kommt also in den Laden zurück, dann beginnt die Uhr von Neuem zu ticken.

Vergleichbar ist es mit der Situation, dass man an der Kasse sein Geld nicht findet, den Korb schnell an der Kasse lässt, um Geld zu holen. Kommt man nun nicht rechtzeitig zurück, dann hat jemand den Korb ausgeräumt und die Waren zurückgestellt.

Die Anzahl der Sessions müsste eigentlich immer gleich der Anzahl der Visits sein. Da aber Visits oft anders gezählt werden, weil geschäftliche Kriterien dahinter stehen und keine technischen, liegen oft die Visits unter der Anzahl der Sessions pro Zeiteinheit.

Wir hoffen, dass diese kurze Erklärung hilft, die Begriffe Visit und Session zu verstehen und auseinander zu halten.

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.

Zur Zeit arbeiten wir intensiv an unseren nächsten Xceptance LoadTest Version.  Sie wird einige interessante Neuerungen mitbringen, die man bisher auf dem Markt noch nicht so gesehen hat:

• Als Scriptsprache steht jetzt neben Java auch Ruby zur Verfügung. Wer also die schnelle agile Entwicklung mit Ruby mag, der kann jetzt nahtlos auch in Ruby Regressions- und Lasttests erstellen.
• Google hat sich die Mühe gemacht und eine einheitliche API zur Programmierung von Webregressiontests ins Leben gerufen – Google Webdriver. XLT spricht jetzt Webdriver. Damit lassen sich schnell Webtests schreiben und, im Gegensatz zu den anderen Tools, auch als Lasttest ausführen. Wir denken, dass damit die Einführung von XLT deutlich schneller geht und sich damit noch besser für Projekte mit Rapid-Prototyping-Charakter eignet.
• Zwei Lasttest-Läufe lassen sich jetzt innerhalb von Sekunden vergleichen und das Ergebnis zeigt schnell und deutlich, wo die Änderungen liegen.
• Wer sich mehr für die langfristige Entwicklung der Performance interessiert ist, dem wird der neue Trendreport eine grosse Hilfe sein. Eine beliebige Menge von Testläufen lässt sich zueinander in Relation setzen und man kann daraus einfach die Entwicklung des Performancetrends ablesen.

Wir freuen uns schon auf die Fertigstellung von XLT 3.3. Zu den einzelnen Neuigkeiten wird es demnächst mehr Blogeinträge geben.

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.

Echt selten, dass die Summe aller Zwischensummen so rund wird. Gefunden beim letzten Lasttest und dabei ist alles recht zufällig.

Nach vielen Lasttests in den letzten Tagen habe ich mal in meine Spezialmailbox geschaut und war ja etwas überrascht, dass es doch schon so viele Emails waren, die in der Zeit eingetrudelt sind. Man stelle sich mal vor, dass wäre alles als auf dem Server hängen geblieben bzw. mit Beschwerde an den Admin gegangen.

Wobei ein Test mit Unzustellbarkeit auch ein schönes Testszenario ist…

Heute habe ich meine Lasttest-Mailbox aufgeräumt, denn es stauten sich mehr als 5000 Test-E-Mails. Aber was ist eine Lasttest-Mailbox?

Für die meisten Testszenarien im E-Commerce-Bereich benötigt man E-Mail-Adressen, weil oft Nutzer über die E-Mail identifiziert, Bestellbestätigungen oder schlicht Passwort-Erinnerungen verschickt werden. Für einige Fälle ist es ausreichend, erdachte Adressen zu verwenden, die nur dem allgemeinen Format einer E-Mail-Adresse (name@server.domain) genügen müssen.

Sobald aber das System unter Test wirklich diese Adressen nutzt und E-Mails verschickt, muss man auf gültige Daten achten, weil sonst das System unter der Flut von Rückläufen zu leiden beginnt und/oder man von den Administratoren eine Verwarnung kassiert.

Die beste Idee wären natürlich jede Menge Postfächer bei Google, aber wenn man 10000 Nutzer mit individuellen E-Mails braucht, dann kann und darf man bei Google keinen Pool anlegen. Allein die Unterscheidung, ob man beim bereits eine E-Mail im Test verwendet hat oder nicht, ist sehr schwer. Zusätzlich ist die Pflege von Testdatensätzen im Allgemeinen sehr zeitintensiv und fehleranfällig.

Wie soll es aber dann gehen?

Bewährt haben sich Catch-All Mailboxen beim eigenen E-Mailprovider oder auch Mailboxen auf virtuellen Servern. Hier kann man eine Domain und eine Mailbox konfigurieren und dann durch das Catch-All unendlich viele E-Mail-Adressen nutzen, die man einfach zufällig erzeugt.

Unter Java 6 ist diese Zeile Code sehr nützlich. Sie erzeugt recht zufällige E-Mail-Adressen mit einer Länge von 15 Zeichen für den Namen. Da die JDK 6 UUID-Klasse genutzt wird, ist eine ausreichende Eindeutigkeit garantiert. Nun gut, eigentlich darf man dann den String nicht einkürzen, aber die meisten Dienste können lange E-Mail-Adressen nicht leiden und so muss man sich beschränken.

final String email =
    UUID.randomUUID().toString().substring(0, 15).
    replaceAll("[^A-Za-z0-9]", "A") + "@yourdomainname54678765.net";

Selbstverständlich muss die Domain yourdomainname54678765.net existieren, einem selbst gehören(!) und das Catch-All der Mailbox dafür korrekt konfiguriert sein.

P.S. Für den Test eines großen E-Mail Dienstes würde ich aber nicht darauf zurückgreifen, weil man zwar viele Mails erzeugen und versenden kann, aber diese Lösung nur für einen moderaten Verkehr ausgelegt ist. Schließlich gehen alle E-Mails den gleichen Weg und nisten sich im selben Briefkasten ein.

Für einen großen Test würde ich wohl eine Serverfarm bei Amazon-EC2 konfigurieren oder 20 virtuelle Server bei verschiedenen Hostern einkaufen.

Ich muss mich heute einfach mal über das Start-And-Go Feature von Xceptance Load Test (XLT) freuen. Früh im Hotel habe ich mich zum Cloud Service verbunden, den Lasttest hochgeladen und gestartet. Danach habe ich das Notebook abgeklemmt und bin Frühstücken gegangen.

Eine Stunde später sass ich im Büro, habe mein Notebook hochgefahren und mich wieder zur Cloud verbunden. Teststatus abgerufen und da der Test durch war, einfach die Ergebnisse runtergeladen.

Es ist echt praktisch, wenn man nicht ortsgebunden für einen Test ist und das Tool einen nicht zwingt, ständig mit den Testmaschinen verbunden zu sein. So machen auch die üblichen Netzunterbrechungen im Hotel oder via UMTS keine Probleme mehr.

Hatte ich schon erwähnt, dass ich beim letzten Mal vom Flughafen, ca. 30 min vor dem Boarding noch mehrere Lasttests laufen hatte? Auch sehr praktisch, dass XLT mit einer Shell auskommt und man den Controller ohne Probleme auf eine Drittmaschine verlagern kann, die man dann via Shell steuert.

Bei der heutigen Sicherheitslage in Rechenzentren bekommt man meist ja nur einen SSH-Zugang mit eigenem Schlüssel und sonst nichts. Aber genau dafür ist XLT gemacht. Mit wenig Ressourcen, viel zu erreichen.