Tag Archives: lasttest

Concurrent Users – The Art of Calculation

Most of you probably know the term Concurrent User. In the context of load and performance testing, this metric is often claimed the measure of all things, accompanied by the mentioning of astronomically high numbers we can’t really verify and that sometimes are simply used as sales argument for overpriced software products.

Today’s article is meant to shed some light on the concurrent user metric and the misunderstandings and myths surrounding it. Since Xceptance focuses on the internet and e-commerce, illustrations and examples will mainly refer to webshops; keep in mind, though, that the topic isn’t restricted to the domain of e-commerce load testing. Feel free to comment below, whether affirmative or critical.

Let’s start with a couple of key terms to help you understand what we’re talking about:

  • Visit: In general, a visit occurs when you send a request to a server and, as a response, the website you requested is displayed. Has a duration starting with the first page view and ends with the last. Consists of one or more page views.
  • Session: Technical term for a visit, basically the technical picture underlying it. Visit and session are often used synonymously.
  • Page view or page impression: A single complete page delivered due to a request of an URL; in a world of Ajax, intermediate logical pages can be considered an impression or view. Can lead to further technical requests (HTML, CSS, Javascript, images etc.)
  • Request: Submission of a request to a server, in the case of web applications mostly via HTTP/HTTPS protocols. Requested content may be HTML, CSS, Javascript as well as images, videos, Flash, or Silverlight applications – HTTP can deliver almost everything.
  • Think time: Time period between two page views of a visit.
  • Scenario: The course of a visit in terms of a use case (for example, to search something, to order something, or both). Representation of test cases meant to be run as load tests.
  • Concurrent User: We don’t exactly know about them yet…

Load and Performance Test

A load test wants to reflect present load conditions or anticipated load conditions. In either case, it’s impossible for a load test to cover all eventualities and be economical at the same time. There’s a myriad of ways you can go to explore a webshop. Thus, you decide on the most typical ones at first and make a scenario out of them afterwards. Most of the time, we consider a scenario an isolated visit repeating the steps of the test case and thus using defined data (note that also random data is defined data).

Let’s assume three scenarios: a visitor that is just looking (Browsing), a visitor that puts products into the cart (Add2Cart), and a visitor that checks out as a guest and wants their ordered items to be shipped to an address (Order).

The users have to go through the following steps to completely cover the scenario:

Browsing user

  1. Homepage
  2. Select a catalogue
  3. Select a subcatalogue
  4. Select a product

Add2Cart user

  1. Browsing 1.-4.
  2. Put a product into the cart

Order user

  1. Add2Cart 1.-2.
  2. Proceed to checkout
  3. Enter an address
  4. Select a payment method
  5. Select a delivery type
  6. Place the order

The first challenge is choosing the content for the single actions, that is should we always go for the same product, the same catalogue, should the number of items or the size of the cart vary, etc. Only these three scenarios offer infinite possibilities of variation already. But let’s stick with the basic steps and the simple Browsing for now.

Concurrent Users

When testing against a server, the single running of Browsing would be a visit consisting of 4 page views and possibly further requests for static content. A second execution of the test with all data and connections (cookies, HTTP-keep-alive, and browser cache) having been reset would result in another visit. If you now run these two visits simultaneously and independently from one another, you end up with two concurrent users. Note that the notion “user” is actually not the exact right term as we’re talking about concurrent visits here. We prefer the term visit in this context and the person performing it is the visitor.

Both of our visitors execute 4 page views each, thus resulting in a total of 8 page views. As each page view has a runtime on the server, let’s say 1 sec, one visit takes at least 4 sec. Therefore, if one user repeats their visits for one hour, he or she completes 3,600 seconds / (4 seconds per visit) = 900 visits / hour. Two concurrent visitors result in 1,800 visits in total leading to an overall total of 1,800 visits x (4 page views per visit) = 7,200 page views.

We just said “if one user repeats”. Of course, a single user would never repeat a visit that many times. Just look at the user here as the load test execution engine repeating that independently of other “users”.

Think times

Now, the majority of users isn’t that fast, of course, which is why usually think times get included. The average think time currently amounts to something between 10-20 seconds, depending on the web presence. It used to be 40 seconds but today’s users are more experienced and user guidance has improved a lot so that they can navigate through a website much faster. Let’s assume a think time of 15 sec for our example.

A visit would now take (4 page views each takes 1 sec) + (3 think times each 15 sec). It’s only 3 think times because there’s none after the last click that terminates the visit. Accordingly, our visit duration is 49 sec. If we now have a visitor repeat that for an hour, we’ll end up with a user completing 3,600 sec / (49 sec per visit) = 73.5 visits per hour.

If we want to test 1,800 visits again, we need 1,800 visits / (73.5 visits per hour per user) = 24.5 users, about 25. The number of page views stays the same since 1 visit equals 4 page views and the number of visits is constant. These 25 users need to complete their visits simultaneously and in parallel but still independent of one another.

Any Number of Concurrent Users is Possible

We now have 25 concurrent users that produce the exact same traffic simulation as 2 users without a think time. The exact same traffic? No, of course not – this is where extreme parallelism and the unpredictability of both testing and reality comes into play.

If the requirement was the simulation of 1,800 visits per hour and 7,200 page views per hour, we could now randomly pick a think time and by doing so, determine any number of concurrent visits aka users between 2 and x. With respect to our simulation period of 1 hour, we get a new session (begin of a visit) every two seconds on the server side – 3,600 sec / 1,800 visits as our visits are equally distributed.

You can also question the numbers by approaching the problem from another perspective: if 100 users are simultaneously active, then they can simultaneously request 100 page views. In the worst case (note that 1 page view takes 1 sec on the server side), however, this would amount to 100 * 3,600 sec = 36,000 page views per hour. Since the requirement of 100 concurrent users is actually never bound to a certain period, you therefore have to assume that these users could potentially click at any time.

From this point of view, you’ll soon realize that the number of concurrent users can basically mean anything: much traffic, little traffic, little load, much load. Only by knowing the test cases and additional numbers such as visits and page views per time unit can you a) define a number of concurrent users and b) check each number by means of calculation against the other numbers.

Oh, and needless to say that 42 is always a good number of concurrent users… ;-)

Why 100,000 Concurrent Users Aren’t 100,000 Visits

What we want to emphasize here is that a temporal dimension is absolutely necessary. The requirement of 300,000 users would always imply they could click simultaneously which would produce 300,000 visits at one blow. Now, you may want to argue that they aren’t coming simultaneously. However, if the users aren’t simultaneously active aka started a visit, they aren’t concurrent users anymore and then you don’t need to simulate them in the first place.

Provided an equal distribution and an average visit duration of 49 sec, 300,000 users per hour that are often identified with visits (business-wise) in most cases, would result in the following: a user completes 3,600 / 49 sec visit duration = 73.5 visits per hour so that you end up with 300,000 / 73.5 = 4,081 concurrent visits aka real concurrent users at any given second. 4,081 concurrent visits produce 4 page views in 49 sec (visit duration) each, that is in 49 sec we have 16,324 page views, thus 333 page views per sec (see next paragraph).

In terms of page views without think times this means: 300,000 users are 1,200,000 page views (for our example above). Thus, you need to complete 1,200,000 page views / 3,600 seconds = 333 page views per second. Without any think time you would therefore need 333 users for the simulation.

Regarding the final result, the simulation of 4,081 users and 15 sec think time therefore equals the simulation of 333 users without think time. On the server side, both will result in the identical number of visits per time period, the identical number of page views, etc.

That’s impossible…

You may raise some objections to this and they are actually valid since, in reality, the think time would never be exactly 15 sec and the response time would never always be 1 sec. This is where coincidence comes into play. With respect to our example, let’s assume the think time to vary between 10 and 20 sec. The arithmetic mean would still be 15 sec.

What happens now results in the following calculation: In the worst case, the duration of all visits is only 4 sec + 3 * 10 sec = 34 sec. With 34 sec, our server now has to deliver as many visits and page views as it delivered within 49 sec before. Thus, our test wouldn’t cover 300,000 users with 4,081 concurrent test users but 3,600 / 34 * 4,081 = 432.105 visits per hour.

That means you need to define target numbers you want to support, or measure what the server is currently able to deliver. As soon as you say you have a number of x visits that could vary in their duration, you end up with a higher maximum number of visits you need to support but that you actually don’t want to test.

Note that our sole focus is set on the load and performance test here. You want to know if you can cope with the traffic x where you assume x to be a constant worst case that applies to a longer period of time. If you want to measure the server side beyond the maximum “good” case, you don’t aim at the performance anymore but at the overload behavior. Then you focus on stability and a predictable way of “decline”. All tests that are normally run at first, which is absolutely correct, are tests that want to identify or verify the good case.

But still…

Of course, it can make sense to test 4,081 users instead of 333 although there’s the same number of visits and page views per time period on the server side. 4,081 users can be concurrent users for a very short time and claim, for example, 4,081 webserver threads or sockets, while 333 users will never reach this number. Even if you keep the think time for 4,081 users at a constant level, the traffic wouldn’t be as synchronous as you planned it to be in the beginning.

In the worst case, you can’t test at all now because each test run leads to a different result. With the restriction to 333 users with none or just minimal think time, you restrict the “movement” of the system at first to measure it. If the system delivers what it should, the test may expand in its width aka both the think times and the number of concurrent users go up.

Steady Load Vs. Constant Arrival Rate

To resolve this dilemma a) without having to consider the server side while b) still being able to measure accurately, you can choose between two typical load profiles:

  • Steady Load: Runs a fixed number of users that wait for the server, for instance, when it has long response times. This way you can’t reach the desired number of visits because users depend on the server’s response behavior. The profile is suitable for controlled measurements.
  • Constant Arrival Rate: Users arrive as new visitors regardless of what is happening on the server side. When the server is too slow, new users will still try to come in. If the server can handle the load, the system runs stable and you just need your user number x (according to our calculation, 4,081, for example). If there are problems on the server side, then the user number automatically increases to x + n (for example, to a total of 10,000 users). In the ideal case, that means you only need 4,081 users but when the server behaves unexpectedly, up to 10,000 users will be activated. This way you can also test the overload behavior at the same time.


We hope you were able to follow and that the mess of numbers didn’t get too bad. At times, the concurrent user topic is getting downright absurd… Feel free to comment, any remark is appreciated.

Availability of Xceptance LoadTest 4.2.0

XLT 4.2.0 delivers a large set of new and improved functionality.

The Script Developer has seen a lot of enhancements. Most noticeably is the support of variables now. You can store data from the web page, run calculations in JavaScript and store the result, and reuse all later. There is now the notion of global and local test data. So any data that applies to multiple test cases at the same time can be managed more easily now. Besides the already mentioned store commands, the Script Developer also permits assertion and wait commands for visibility, select and check boxes, as well as value attributes of an element.

Further usability improvements permit easier switching between projects and the execution of a single command in a test case for faster development. Test cases can now be run directly from the package tree without the need to open them first. The test data management has been completely reworked to simplify and speed up editing of data.

The load test engine supports a fully variable load test profile now. You can define any load pattern you want, such as a 24 hour test with peaks around noon and early afternoon, low traffic during night hours, slow ramp up in the morning and multiple load changes over the course of the day. Additionally the ramp up of arrival rates is now supported as well.

To speed up things and fully utilize the available connectivity, the upload to and the download from agents has been fully parallelized. Optionally you can adjust the desired concurrency. Also the timeout against agents can now be set.

The documentation layout as well as the report design have been redesigned to improve usability, make them visually more pleasant, and unify their appearance. Third party libraries used to deliver enhanced functionality have been upgraded to cover the latest browsers as well as UI trends.

Please see the detailed release notes for more information about new features, enhancements, and defect fixes.

Was sind Visits, was sind Sessions?

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.

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.

Lasttesten mit Webdriver und Ruby

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.

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:


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


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


  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.

Nach dem Lasttest

Ein Blick in die Lasttest-Mailbox

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, das 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…


Bild meiner Lasttest-Mailbox

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.

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.