Tag Archives: test

Bugs in the Wild, Testing

Tracking and Ad-Blocker Software

Summary in 64 words

Ad blockers are widely used tools these days. Users install this software to improve loading times of websites or to simply remove intrusive advertisement. But what does this mean for us as a testing company? We saw some sites break and are now including tests with enabled ad blockers. This helps our customers to see where problems might occur and to improve user experience.

Introduction

The amount of advertising increases and more and more users take this matter in their own hands and install ad blockers. Users also become privacy-conscious and do not want to expose their browsing behavior to an ever increasing number of companies. Facebook’s, Twitter’s, and Google’s ad or content pixels are on nearly every page nowadays. Adobe collects data as well with font services, Scene7, and Omniture. There are lots of big and small third parties that live on pages and are included as a service. We have seen websites with over 50 third party services on a single page of their web shop.

Continue reading Tracking and Ad-Blocker Software →

Testing, Testing Culture

Another Six Things You Should Never Say to a Software Tester

Inspired by this UTest article 6 Things You Should Never Say to a Software Tester, we came up with additional six comments a software tester does not really like to hear:

But it works on my development machine!

We don’t doubt that, really. But a sandbox is called a sandbox for a reason. It’s a playground, a simulation of reality, with its own rules and regulations. Kids fight about sand castles first before moving on to arguing about real estate in the grown-up world, so please throw away your shovel for a second and join us in the real world!

You broke it.

“No, I didn’t!” – “Yes, you did!” – “NO, I DID NOT!” and so on… That was me and my friend in kindergarten, at the age of 4. The toy was in pieces and none of us could (or would) recall whose fault it was. And it didn’t really matter at this point. The more important question was how to hide the broken thing from the teacher to avoid any unpleasant consequences. Once we had figured that out, we were done with the argument and started working together. A good example for how you can learn from past mistakes.

Your test report says you executed all of the test cases, so there won’t be any new bugs from now on, right?

“You’ve eaten all the pasta, that means you’ll never be hungry again, right?” – If you think this is an absurd example, read the third statement again. See the analogy?

You’re testing e-commerce sites? Oh, so you’re basically shopping online all day long?

Yes. And no. I don’t need 100 luxury bathrobes embroidered with profanities, and I also don’t want them. I also don’t have a second home in Hawaii and I know that entering incomplete billing information won’t take me to the next step in checkout. And yet I simulated all these scenarios while testing. Testing an e-commerce site is different from ordinary online shopping, especially since the term “ordinary online shopping” has yet to be defined. Am I the grandmother who just got an iPad for Christmas and is now looking for bargains? Am I the hipster who is annoyed by all the promotions that are thrown at him while he just wants to get his shopping done? Is the website prepared for the most challenging checkout attempts? It is our job to find that out, and it has little to do with “online shopping”. Though I did try to pay my last purchase at the farmer’s market with a test credit card, but that’s another story…

I see your point, but it’s not a requirement.

So it’s not a requirement that the password field should be cleared out after submitting the form? Instead of treating the documentation as a bible, we’d appreciate the use of common sense more often. We know that there’s the tight schedule and the even tighter budget and that those things don’t allow for many extras. But, believe us, a password that floats around unattended on a page is not an extra, but it can hit you hard when it comes back to you later.

This is no longer a bug, please see the updated requirements.

This is even worse if it comes along with the previous statement. It should not be an acceptable solution to turn a defect into a requirement. If it happens and the alleged bug turns into a butterfly, that is if the requirements change, please! let! the! testers! know! We don’t like to spend our time hunting fake bugs, therefore we need to know about any updates as soon as possible. And yes, this also includes design changes!

What else comes to your mind?

Performance, XLT

Concurrent Users – The Art of Calculation

5 Comments

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.

Finally…

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.

Performance

Ist die Geschwindigkeit ein Teil des Pagerank?

2 Comments

In diesem Interview mit SEO marketing expert Amanda Watlington ist die Rede davon, dass Google die Geschwindigkeit einer Website in die Platzierung im Suchergebnis einfließen lässt.

Google is now using page loading speed in their ranking algorithm. The engineering of some sites can make this a difficult problem to fix quickly, so webmasters should study the problem now with speed detection tools such as YSlow and Google Page Speed.

Das wäre nur konsequent von Google, da bereits die Webmaster-Tools in der Google-Administration die Seitengeschwindigkeit ausweisen. Zudem profitiert Google von schnellen Webseiten indirekt, da der Aufwand für die Indizierung sinkt bzw. die Updatezyklen kürzer sein können. Damit steigt auch die Aktualität von Suchergebnissen und das verbessert die Wettbewerbssituation für Google.

Wir freuen uns natürlich auch darüber, weil damit nicht zuletzt auch die Bedeutung von Last- und Performancetests steigt.

Testing

Was QA nicht machen soll

Es gibt immer große Missverständnisse über die Rolle von QA/Test. Einige Leute wollen, dass QA das Produkt explizit freigibt und notfalls es aufhält, wenn es schlecht ist. Andere meinen, dass es besser ist, wenn QA einfach nur eine Empfehlung ausspricht.

Jon Bach hat heute auf der STPCon 2009 mit einem kurzen Satz schön zusammengefasst, welche Aufgabe QA hat. Ich teile seine Ansicht voll.

QA does not make quality. QA helps to make an informed decision about the quality.

QA/Test stellt den Zustand der Software/Hardware fest und informiert darüber. QA wird sich auf keinen Fall die Aufgabe auf den Tisch ziehen, zu richten. Das soll bitteschön der Auftraggeber, Programmmanager oder Projektmanager machen. Er bekommt den Bonus, er darf entscheiden. QA hilft nur dabei und zwar so gut, dass er eigentlich nicht anders kann, als der QA-Empfehlung zu folgen.

Performance, Software Development, XLT

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.

Bugs in the Wild

Abbrechnen – Wenn Worte zu ähnlich sind

Wenn Worte zu ähnlich sindHeute habe ich sichtlich verwirrt geschaut und gesucht, wie ich mir beim Spiegel eine Online-Ausgabe kaufen kann, denn im Bestellprozess steht plötzlich Abrechnen auf einem Button.

Abrechnen habe ich noch nie gelesen. Meist steht nur Weiter, Kaufen oder Bestellen drauf. Das Problem ist, dass man auf den ersten Blick nämlich Abbrechen liest.

Da fällt mir das schöne Kunstwort Abbrechnen ein…

Security, Testing

Passwörter prüfen leichtgemacht

Wer schon immer mal wissen wollte, ob seine Passwörter ansatzweise sicher sind, der sollte das The Password Meter ausprobieren. Das Ding ist wirklich pingelig. Was andere Prüfwerkzeuge als stark und superstark bewertet haben, das fällt bei The Password Meter unter: 0% – Vergiss es Dude!

Die Anwendung steht unter GPL und kann runtergeladen werden. Das gute Stück ist 100%-Javascript und die Eingaben werden nicht übertragen. Man sollte aber trotzdem nicht seine echten Passwörter eingeben, sondern ähnliche Muster. Also statt Helga78 tut es ein Katja87 :)

Das Ganze ist kein Informatiker-Geek-Spiel sondern wirklich ernst. Viele 0815-Internetnutzer haben solche weichen Passwörter, dass es ein Wunder ist, dass sie noch nicht ausgeplündert wurden.

Performance, Testing

Parallele Nutzer – die Kunst der Berechnung

2 Comments

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.