So what to do, when you do not know every detail about the current or future load pattern? We are describing one approach below that was very successful so far and always yielded satisfying results.

What we need

• Visits per peak hour (example 10k)
• Page views per peak hour (example 100k)
• Orders per peak hour (example 200 orders)
• Optionally we can use the conversion rate to get from visits to orders or vice versa.
• Optionally we can take searches, “add to cart” operations, user registrations, and so on into account.

The mentioned scenarios are typical ecommerce scenarios and look like that. We will not talk about smaller scenarios such as address editing for a registered user.

• TSingleClickVisit: Enters the store only, does not move beyond the start page
• TBrowsing: TVisitor plus category and product browsing
• TSearch: TVisitor plus keyword search plus browsing of the result
• TAdd2Cart: TBrowsing plus add to cart operations
• TGuestCheckout: TAdd2Cart plus checkout without an order placement (anonymous user)
• TGuestOrder: TAdd2Cart plus full checkout (anonymous user)
• TRegisteredCheckout: TAdd2Cart plus checkout without an order placement (registered customer)
• TRegisteredOrder: TAdd2Cart plus full checkout (registered customer)
• TRegistration: Account creation

What we assume

Ecommerce sites follow similar patterns and with a few exceptions, such as special promotions, certain behavioral patterns are nearly identical. So for instance, about 50% of all checkouts are stopped before the order is placed. About 20 to 50% of all created carts aren’t checked out at all.

What we calculate

Based on these assumptions, we put together a fairly simple but sufficiently accurate load mix. Of course, we can also analyze the current log files and try to come up with something more precise, but that will be a snapshot only. Traffic is very volatile and so we should be very generous when setting up this mix.

Since we do not take any daily averages as base but the peaks, we will have a pretty comfortable buffer for our daily ecommerce life anyway.

Bottom-Up

Let’s say, 200 orders are set as goal. Splitting them 50/50  between registered and anonymous users, we get 100 visits of each type. All numbers are per hour of course.

• TGuestOrder = 100
• TRegisteredOrder = 100

As a next step, we take our 50% checkout abandonment rate into account. We have 200 checkouts per hour that are stopped and 200 that run through and turn up as orders (as counted previously). So we need to add 200 visits. And because these visitors can either run with their preset account or without, we split them up in 100 guest and 100 registered checkout attempts.

• TGuestCheckout = 100
• TRegisteredCheckout = 100
  
• TGuestOrder = 100
• TRegisteredOrder = 100

This gives us 400 visits per hour that go into the checkout. We now assume a low cart to checkout conversion rate, about 20% for instance, and so we take 400 checkout visits * 5 and get 2,000 visits that involve cart usage. Since we already have 20% converted into checkouts, we have 2,000 minus 400 visits that use the cart.

• TAdd2Cart = 1,600
• TGuestCheckout = 100
• TRegisteredCheckout = 100
• TGuestOrder = 100
• TRegisteredOrder = 100

We also know that many users do not continue after hitting the home page or any landing page. Let’s add some of these users now.

• TSingleClickVisitor = 1,000
• TAdd2Cart = 1,600
• TGuestCheckout = 100
• TRegisteredCheckout = 100
• TGuestOrder = 100
• TRegisteredOrder = 100

But wait, what are we missing? Well, we have not registered any new accounts yet. Didn’t we? We did, because the registered checkout creates accounts if required and reuses them several times. But to get a more substantial customer growth, we simply add 200 visits that run registrations:

• TRegistration = 200
• TSingleClickVisitor = 1,000
• TAdd2Cart = 1,600
• TGuestCheckout = 100
• TRegisteredCheckout = 100
• TGuestOrder = 100
• TRegisteredOrder = 100

What is left to do? Well, we do not have any “I am just looking around”-visitors yet. We know that our total visit count is 10,000 and we already assigned 3,200 of these to cart, checkout, and registration, so we have 6,800 visits left we can now use for something else. Depending on the shop type (large store, small store etc), people tend to use search more or less. To put enough stress on search and refinements, we simply assume 50% of all people like to search. Thus the missing 6,800 visits will be 3,400 catalog browser visits and 3,400 visits with usage of search before browsing the search result.

The total mix is:

• TBrowsing = 3,400
• TSearch = 3,400
• TRegistration = 200
• TSingleClickVisitor = 1000
• TAdd2Cart = 1,600
• TGuestCheckout = 100
• TRegisteredCheckout = 100
• TGuestOrder = 100
• TRegisteredOrder = 100

Wait… where are my concurrent users? This is simple: “concurrent users” is an inaccurate way of describing traffic, so we have not used that number yet. Why is that?

To get to the bottom of that, we simply check how long a visit takes. Depending on the shop, an average visit might take 2 to 4 minutes. Successfully shopping might take 15 minutes. If we expect about 10 page views per visit and a page view takes 1 second to load and 20 seconds to read it (already a really really high number for an average), a visit would take 10 * 1 second + 9 * 20 seconds = 190 seconds.

Let’s go with the 190 seconds for a visit on average. If we just could serve one visitor at a time, we could serve 60 minutes (3600 seconds) / 190 seconds per visits = 19 visitors per hour. But because we would like to serve 10,000 per hour, we have to deal with 10,000 / 19 = 526 visitors at the same time. This is the famous concurrent user number.

If we now double the think time, we have 1,052 concurrent users/visitors. If we cut it down to 1 second think time, we will get a visit length of 19 seconds and therefore 10,000 visits / (3600 seconds / 19) = 53 concurrent visitors.

So we already have three different “concurrent user” numbers and are still simulating the same traffic. This shows that the number of concurrent users is a pretty questionable way of describing traffic.

It does not matter which number we take, because most of the time the servers will see the same traffic. Because we run against a SaaS environment that serves a multiple of other customers at the same time and is sized to serve the peak traffic for all customers at the same time, we have plenty of comfortable room around us. This permits us to run with 53 concurrent visitors for most of the testing. This will save us client hardware resources for the load generation. e.g. saves us money. We are basically only interested in the runtime of requests and not if the environment can handle that, because it can.

The goal of this test is to demonstrate that the implementation on the SaaS platform is efficient, not that the SaaS platform itself is fast and stable, because this is guaranteed by design and contract. Testing this would require way more traffic and generate huge costs, because the environment would suddenly no longer be a shared one but exclusively used for this testing purpose.

When finalizing the entire test and all tests turned out good, we are going to turn up the concurrent user count to 530 users and compare the result with the previous measurements. Just to satisfy the traditional test expectations.

Does that work for you?

Hope that gives you an idea how to come up with a nice user mix for testing without having too much data in the first place. Comments welcome.

I believe in the power, speed and “update-ability” of CSS3. Not having to load background images as structural enhancements (such as PNGs for rounded corners and gradients) can save time in production (i.e. billable hours) and loading (i.e. page speed). At our company, we’ve happily been using CSS3 on client websites for over a year now, and I find that implementing many of these properties right now is the most sensible way to build websites.

Until today, all of that was based on an assumption: that I can produce a pixel-perfect Web page with CSS3 quicker than I can with older image-based CSS methods, and that the CSS3 page will load faster, with a smaller overall file size and fewer HTTP requests. As a single use case experiment, I decided to design and code a Web page and add visual enhancements twice: once with CSS3, and a second time using background images sliced directly from the PSD. I timed myself each round that I added the enhancements, and when finished, I used Pingdom to measure the loading times.

More…

Enjoy reading.

HTTP-level tools record HTTP requests on the HTTP protocol level. They usually provide functionality for basic parsing of HTTP responses and building of new HTTP requests. Such tools may also offer parsing and extraction of HTML forms for easier access to form parameters, automatic replacement of session IDs by placeholders, automatic cookie handling, functions to parse and construct URLs, automatic image URL detection and image loading, and so on. Extraction of data and validation are often done with the help of string operations and regular expressions, operating on plain HTTP response data. Even if HTTP-level tools address many load testing needs, writing load test scripts using them can be difficult.

Challenges with HTTP-Level Scripting

Challenge 1: Continual Application Changes

Many of you probably know this situation: A load test needs to be prepared and executed during the final stage of software development. There is a certain time pressure, because the go-live date of the application is in the near future. Unfortunately, there are still some ongoing changes in the application, because software development and web page design are not completed yet.

Your only chance is to start scripting soon, but you find yourself struggling to keep up with application changes and adjusting the scripts. Some typical cases are described below.

• The protocol changes for a subset of URLs, for example, from HTTP to HTTPS. This could happen because a server certificate becomes available and the registration and checkout process of a web shop, as well as the corresponding static image URLs, are switched to HTTPS.
• The URL path changes due to renamed or added path components.
• The URL query string changes by renaming, adding or removing URL parameters.
• The host name changes for a subset of URLs. For example, additional host names may be introduced for a new group of servers that delivers static images or for the separation of content management URLs and application server URLs that deliver dynamically generated pages.
• HTML form parameter names or values are changed or form parameters are added or removed.
• Frames are introduced or the frame structure is changed.
• JavaScript code is changed, which leads to new or different HTTP requests, to different AJAX calls, or to a new DOM (Document Object Model) structure.

In most of these cases, HTTP-level load test scripts need to be adjusted. There is even a high risk that testers do not notice certain application changes, and although the scripts do not report any errors, they do not behave like the real application. This may have side effects that are hard to track down.

Challenge 2: Dynamic Data

Even if the application under test is stable and does not undergo further changes, there can be serious scripting challenges due to dynamic form data. This means that form field names and values can change with each request. One motivation to use such mechanisms is to prevent the web browser from recalling filled-in form values when the same form is loaded again. Instead of “creditcard_number”, for example, the form field might have a generated name like “cc_number_9827387189479843″, where the numeric part is changed every time the page is requested. Modern web applications also use dynamic form fields for protection against cross-site scripting attacks or to carry security-related tokens.

Another problem can be data that is dynamically changing, because it is maintained and updated as part of the daily business. If, for example, the application under test is an online store that uses search-engine-friendly URLs containing catalog and product names, these URLs can change quite often. Even worse, sometimes the URLs contain search-friendly catalog and product names, while embedded HTML form fields use internal IDs, so that there is no longer an obvious relation between them.

Session IDs in URLs or in form fields may also need special handling in HTTP-level scripts. The use of placeholders for session IDs is well supported by most load test tools. However, special script code might be needed, if the application not only passes these IDs in an unmodified form, but also uses client-side operations on them or inserts them into other form values.

To handle the above-mentioned cases, HTTP-level scripts need manually coded, and thus unfortunately also error-prone, logic.

Challenge 3: Modeling Client-Side Activity

In modern web applications, JavaScript is often used to assemble URLs, to process data, or to trigger requests. The resulting requests may also be recorded by HTTP-level tools, but if their URLs or form data change dynamically, the logic that builds them needs to be reproduced in the test scripts.

Besides this, it can be necessary to model periodic AJAX calls, for example to automatically refresh the content of a ticker that shows the latest news or stock quotes. For a realistic load simulation, this also needs to be simulated by the load test scripts.

Challenge 4: Client-Side Web Browser Behavior

For correct and realistic load simulations, the load test tool needs to implement further web browser features. Here are a few examples:

• Caching
• CSS handling
• HTTP redirect handling
• Parallel and configurable image loading
• Cookie handling

Many of these features are supported by load test tools, even if the tools act on the HTTP level, but not necessarily all of them are supported adequately. If, for example, the simulated think time between requests of a certain test case is varied, a low-level test script might always load the cacheable content in the same way – either it was recorded with an empty cache and the requests are fired, or the requests were not recorded and will never be issued.

DOM-Level Scripting

What is the difference between HTTP-level scripting tools and DOM-level scripting tools? The basic distinction between the levels is the degree to which the client application is simulated during the load test. This also affects the following characteristics:

• Representation of data: DOM-level tools use a DOM tree instead of simple data structures.
• Scripting API: The scripting API of DOM-level tools works on DOM elements instead of strings.
• Amount and quality of recorded or hard-coded data: There is much less URL and form data stored with the scripts. Most of this data is handled dynamically.

DOM-level tools add another layer of functionality on top. Besides the handling of HTTP, these tools also parse the contained HTML and CSS responses to build a DOM tree from this information, similar to a real web browser. The higher-level API enables the script creator to access elements in the DOM tree using XPath expressions, or to perform actions or validations on certain DOM elements. Some tools even incorporate a JavaScript engine that is able to execute JavaScript code during the load test.

Advantages

DOM-level scripting has a number of advantages:

• Load test scripts become much more stable against changes in the web application. Instead of storing hard-coded URLs or data, they operate dynamically on DOM elements like “the first URL below the element xyz” or “hit the button with id=xyz”. This is especially important as long as application development is still ongoing. As a consequence, you can start scripting earlier.
• Scripting is easier and faster, in particular if advanced script functionality is desired.
• Validation of result pages is also easier on the DOM level compared to low-level mechanisms like regular expressions. For example, checking a certain HTML structure or the content of an element, like “the third element in the list below the second H2” can be easily achieved by using an appropriate XPath to address the desired element.
• Application changes like changed form parameter names normally do not break the scripts, if the form parameters are not touched by the script. But, if such a change does break the script because the script uses the parameter explicitly, the error is immediately visible since accessing the DOM tree element will fail. The same is true for almost all kinds of application changes described above. Results are more reliable, because there are fewer hidden differences between the scripts and the real application.
• CSS is applied. Assume there is a CSS change such that a formerly visible UI element that can submit a URL becomes invisible now. A low-level script would not notice this change. It would still fire the old request and might also get a valid response from the server, in which case the mismatch between the script and the changed application could easily remain unnoticed. In contrast, a DOM-level script that tries to use this UI element would run into an error that is immediately visible to the tester.
• If the tool supports it, JavaScript can be executed. This avoids complicated and error-prone re-modeling of JavaScript behavior in the test scripts. JavaScript support has become more and more important in recent years with the evolution of Web 2.0/AJAX applications.

Disadvantages

There is one disadvantage of DOM-level scripting. The additional functionality needs more CPU and main memory, for instance to create and handle the DOM tree. Resource usage increases even more if JavaScript support is activated.

Detailed numbers vary considerably with the specific application and structure of the load test scripts. Therefore, the following numbers should be treated with caution. Table 1 shows a rough comparison, derived from different load testing projects for large-scale web applications. The simulated client think times between a received response and the next request were relatively short. Otherwise, significantly more users might have been simulated per CPU.

If you evaluate these numbers, please keep in mind that machines are becoming ever more powerful and that there are many flexible and easy-to-use on-demand cloud computing services today, so that resource usage should not prevent DOM-level scripting.

Conclusion

Avoid hard-coded or recorded URLs, parameter names and parameter values as far as possible. Handle everything dynamically. This is what we have learned. One good solution to achieve this is to do your scripting on the DOM level, not on the HTTP level. If working on the DOM level and/or JavaScript execution are not possible for some reason, you always have to make compromises and accept a number of disadvantages.

We have created and executed web-application load tests for many years now, in a considerable number of different projects. Since 2005, we have mainly used our own tool, Xceptance LoadTest (XLT), which is capable of working on different levels and supports fine-grained control over options like JavaScript execution. In our experience, the advantages of working on the DOM level, in many cases even with JavaScript execution enabled, generally by far outweigh the disadvantages. Working on the DOM level makes scripting much easier and faster, the scripts handle many of the dynamically changing data automatically, and the scripts become much more stable against typical changes in the web application.

Ronny Vogel is technical manager and co-founder of Xceptance. His main areas of expertise are test management, functional testing and load testing of web applications in the field of e-commerce and telecommunications. He holds a Masters degree (Dipl.-Inf.) in computer science from the Chemnitz University of Technology and has 16 years of experience in the field of software testing. Xceptance is a provider of consulting services and tools in the area of software quality assurance, with headquarters in Jena, Germany and a branch office in Cambridge, Massachusetts, USA.

Most modern programming languages are virtual machine based and these machines have knobs you can turn to adjust their behavior according to your requirements. XLT runs on Java and so all the things you might have already learnt from tuning your Java-based servers apply to XLT as well. If you do not have experience in tuning your Java-based servers, you will learn a lot that can be applied to your servers and help you to increase performance.

So, let’s take a look at the upcoming XLT feature that provides you with more details about garbage collection (GC) without the need to use any external tool to monitor or analyze logs or JVMs runtime behavior.

Perfect GC behavior

This is a chart displays nice memory statistics that indicate absolutely no problems with the garbage collection. As you can see the memory usage (first chart in the image) is alternating but never touching the upper limit. The second chart gives you the times when full garbage collection occurred, basically these are the bad events. Events that block the virtual machine from continuing to run. We should avoid these at any cost… nearly, because a full GC is costly. There was only one full GC right at the beginning at the test. This is a normal JVM behavior. So we seem to have done a pretty good job. No major collection of garbage. Sweat!

There are still the minor collections. Minor collections occur frequently and they reclaim small portions of memory with short living objects. The third charts shows us, that minor collection took about 10 to 30 ms, some spikes up to 70 ms. This is acceptable.

GC with Issues

Ok, let’s have a bad example in comparison. It runs with almost default VM settings. This means just min and max heap were set (Xms256MB/Xmx512MB). You can see clearly that a lot of major collections were running for up to 800 ms each. Also the minor collections were longer.

Clearly, the new charts help you see and fix misbehavior quickly. “What about the settings?” you might ask now. Yes, this example is not very helpful without revealing the difference between both test runs. So, we will give you the settings of the good one. The bad run had only Xms and Xmx set, as mentioned before.

## Set minimum memory to use
-Xms512m

## Set maximum permitted memory
-Xmx512m

## Enable concurrent old GC to avoid sudden long pauses
-XX:+UseConcMarkSweepGC

## When to start GC for the tenured/old area of the memory.
## This has to be low enough to avoid that threads need
## memory and can not get any before the GC has finished.
## This will lower the wait time.
-XX:CMSInitiatingOccupancyFraction=70

That’s really all. The use of the Concurrent-Mark-Sweep-Collector (CMS) is the most important setting. The CMS does not block the main VM worker threads, but collects the garbage concurrently. Because there might be situations were the CMS collector is not fast enough in cleaning up, this means the old space runs out of free memory, we give the CMS a hint with the last line. This line explicitly tells the CMS to start early with the clean up. In this case at a 70% fill level. The default is 96% and way too high.

One last thing. Setting Xms and Xmx to the same number helps the VM to relax because it will not try to get back to the minimal memory limit (Xms) and so it cleans less aggressively.

If you want to lean more about Java Garbage Collection, take a look at this Oracle documents: GC Tuning.

Script Developer

As an alternative to writing test cases in Java, you can now use the XLT Script Developer to create script test cases. Script test cases are based on a simple syntax and a reduced set of operations, which makes them a perfect fit for non-programmers. Only the Script Developer, which is an extension to Firefox, is necessary to create, edit, and manage basic script test cases.

To create a new script test case, the test designer simply uses the application under test. All interactions with the application are recorded in the background and stored to an XML script file as a sequence of script commands. While recording, assertion commands to validate the web pages may be inserted manually. From the Script Developer, script test cases can be replayed in Firefox at any time to quickly check whether the test case still runs successfully.

Existing script test cases can be modified later on, for example, to add new or delete obsolete commands. Common command sequences, which could be reused in other test cases as well, can be refactored to parameterizable script modules. Finally, any recorded value can be extracted out of the script into a test data file to separate test data from script code.

Script files can also be run outside of the browser, via the XLT framework, which simulates a head-less browser. This mode is suitable for unattended test case execution, during functional or load tests. When saving scripts, the Script Developer also creates JUnit test case classes as “wrappers” around script test cases, which serve as a bridge between the XLT framework and the script world. This way, from the framework’s point of view, script test cases are in no way different from test cases written in Java.

More Data to Query

For improved tests accuracy, you can now query the request and response data and run assertions on it. This permits checks on the communication because not all requests are reflected in the DOM tree.

Improved EC2 Handling

AWS (Amazon Web Services) added the ability to tag EC2 resources to simplify the administration of your cloud infrastructure. As a form of meta data, tags can be used to create user-friendly names and improve coordination between multiple users. The XLT EC2 administration tool ec2_admin features an additional menu which lets you select your EC2 resources based on the tag name.

Better Automation

To improve automation of tests, we added the ability to pass properties on the mastercontroller command line. Additionally the test definition file for the test suite can be redefined on the command line as well.

Faster Work Flow

When test goes wrong or a logging is turn up, the data to download from all agents can be pretty big. To get a fast or selective result, you can now decide how much data you want to download.

JDK Compatibility

Beginning with v4.0, XLT requires a Java virtual machine 6 or above to run. Java 5 is not supported any longer. The reason is the end-of-life announcement for JDK 5.

Misc

We refreshed HtmlUnit and updated it to version 2.8, Ruby got updated to 1.5.1, and WebDriver is now v2.0a6. The event API got simplified and is now easier to use.

Where to get it

More information about the release, the quick start guide, and the manual can be found in the release area. Of course, the full download of XLT 4.0 is available there too. 

We are looking forward to your feedback, comments, and of course… Happy testing!

40-60% of Yahoo!’s users have an empty cache experience and ~20% of all page views are done with an empty cache. … It says that even if your assets are optimized for maximum caching, there are a significant number of users that will always have an empty cache. …reducing the number of HTTP requests has the biggest impact on reducing response time. The percentage of users with an empty cache for different web pages may vary, especially for pages with a high number of active (daily) users. However, we found in our study that regardless of usage patterns, the percentage of page views with an empty cache is always ~20%.

A short ramp up period in the beginning of the test and afterwards we kept a steady load factor. For the steady phase we reached more than 11,000 hits per second.

The target system was seeing about 2,200 concurrent users during the peak of the test.

During that test, the network was transporting about 95 Mbytes/s inbound traffic, this is a network utilization of about 760 Mbit/s. Amazing that the EC2 boxes in the EU data center can handle that traffic. We used just 10 boxes and each box has a 100Mbit network, so the overall limit must have been reached we think.

By the way, the target system recovered easily and was able to serve its normal duties without any problems. But this test clearly showed the limits in terms of throughput. But this test did not show any limits of XLT 4.0, because neither the load boxes in terms of CPU nor the reporting had any problems with this test size.

Well, let me first say that test environments exist for exactly that purpose. So if you already have something live, of course you used it before going live for load testing, and now you cannot run another test there… yes, you need a test environment. This is well spent money for several reasons:

• Created data will not pollute your installation aka log entries, analytics data, orders in the database, created users, and so on.
• You do not have to take your live site down for testing.
• Problems during testing will not leave your live site down or take it down.
• Your hosting company or IT department might charge for all test traffic against the live site as it would have been real traffic (revenue share, bandwidth utilization), so having your own testing realm makes expenses more predictable.
• You can easily change code and retest when changes are necessary. You can profile, you can debug.
• You do not risk problems with traffic going to live systems, such as payment due to configuration or testing errors. If you already had items from test orders piling up in your office, you know what I mean.

So, get yourself a test environment. Spend the money and enjoy the freedom to measure, debug, and tune.

P.S. Of course, there are situations, where you cannot replicate a live environment or you cannot find application problems in a test setup due to totally different timing behavior… Well, this indicates only that your live environment is already screwed.

So, the G1 is not yet ready for production, of course nobody stated that it is ready for production. If I read the release notes of JDK6u21 correctly, it delivers plenty of G1 changes, so I might try that soon.

There is a free PDF version of the magazine that requires an online registration, where your e-mail address and country are required fields.

Enjoy reading!

Last month Google added Website speed to its site ranking algorithm: It’s Official: Google Now Counts Site Speed As A Ranking Factor… The rationale behind this move by Google is fairly straightforward:

Slow web sites lead to a poor user experience, and therefore should not appear at the top of the search list even if they contain relevant content.

This emphasizes once more the influence of performance on your daily business. A simple change to your site can now affect your entire page ranking and how users find your content. Continuous performance testing is now even more important than ever.

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.

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.

• Lasttest: Bei einem Lasttest wird die zukünftige Nutzung des zu testenden Systems unter Berücksichtigung bestimmter Benutzer- und Transaktionsmengen simuliert und bewertet. Dabei werden zwei grundsätzliche Ziele verfolgt. Das erste Ziel ist die Aufdeckung funktionaler Fehler, die nur unter paralleler oder intensiver Nutzung des Systems auftreten. Das zweite Ziel ist die Überprüfung des Zeit- und Verbrauchsverhaltens des getesteten Systems unter einer gegebenen Last. Dabei werden beispielsweise Antwortzeiten sowie der Verbrauch von Hauptspeicher und Rechenleistung ermittelt. Lasttests können auf unterschiedliche Aspekte eines Systems ausgerichtet sein. Dafür sind jeweils auch unterschiedliche Lastprofile und Testszenarien erforderlich, die oft mit eigenen Begriffen bezeichnet werden. Beispiele dafür sind “Skalierungstest”, “Stresstest” oder “Dauerlasttest”. Der Begriff “Lasttest” ist der Oberbegriff für alle diese Testarten.
• Stresstest: Bei einem Stresstest wird die simulierte Last über das im Normalbetrieb erwartete Maß erhöht, bis funktionale Fehler auftreten oder das Antwortverhalten des getesteten Systems bestimmte Grenzen überschreitet. Hierfür wird oft eine kontinuierlich ansteigende Nutzerzahl simuliert. Stresstests verwendet man beispielsweise zur Ermittlung des Systemverhaltens in und nach Überlastsituationen, zur Ermittlung der maximal akzeptierbaren Last oder zum Finden von Performance-Schwachstellen (Bottlenecks).
• Dauerlasttest: Dauerlasttests sind Lasttests, die kontinuierlich über einen längeren Zeitraum laufen. Ziel ist die Prüfung der Langzeitstabilität des getesteten Systems sowie des Ressourcenbedarfs (Memory Leaks!) und das Antwortzeitverhaltens. Die Testdauer beträgt meist 12h bis mehrere Tage. Es wird beispielsweise die später im Produktivbetrieb erwartete Last oder eine Last etwa 30% unter der im Stresstest ermittelten Maximallast simuliert. Dauerlasttests werden auch Stabilitätstests genannt.
• Fail-Over-Test: Ein Fail-Over-Test prüft Hochverfügbarkeitseigenschaften einer Anwendung. Dazu werden während der Lastsimulation der Ausfall und der Wiederanlauf einzelner, redundant ausgelegter Systemkomponenten provoziert und die korrekte Reaktion (Fail-Over) des Systems geprüft.
• Performance-Test: Der Begriff Performance-Test wird nicht immer einheitlich verwendet. Teilweise meint man damit einen Test, der die Einhaltung der vorgegebenen Lastanforderungen prüft, indem man die geforderte Last simuliert und das Verhalten des Systems mit den Anforderungen an Antwortzeiten, Durchsatz usw. vergleicht. Teilweise wird von einem Performancetest gesprochen, wenn der Test Bottlenecks aufspüren soll, ohne das getestete System zu überlasten. Dazu werden während der Testläufe detaillierte Monitoring-Informationen über alle Hardware- und Softwarekomponenten gesammelt und ausgewertet. Gelegentlich wird der Begriff auch synonym zum Oberbegriff “Lasttest” benutzt.
• Sizing-Test: Mit einem Sizing-Test bestimmt man den Umfang der benötigten Hardware und Software für bestimmte Lastanforderungen. Dazu werden die Grenzen unterschiedlicher Hardware-/Software-Konfigurationen ermittelt, um später auf Basis gegebener Lastanforderungen Schätzungen zur voraussichtlich benötigten Hardware und Software durchführen zu können.
• Skalierbarkeitstest: Mit einem Skalierbarkeitstest wird erstens geprüft, wie sich das Antwortverhalten und der Ressourcenverbrauch eines Systems mit steigender Last verändern. Im Idealfall steigen die Antwortzeiten linear zur Last. In diesem Bereich “skaliert” das System. In realen Systemen verschlechtert sich dieses Verhalten mit zunehmender Last, so dass eine weitere Lasterhöhung ab einem gewissen Punkt einen stark überproportionalen Anstieg der Antwortzeiten zur Folge hat. Damit ist die Grenze der Skalierbarkeit erreicht. Es wird also getestet, wie stark die Last auf einem gegebenen System erhöht werden kann, bis diese Grenze erreicht ist. Zweitens ist zu testen, inwiefern sich diese Grenze durch Hinzunahme von Hardware- und Softwarekomponenten nach oben verschieben lässt. Solange die maximal verarbeitbare Last annähernd linear mit der Menge der eingesetzten Komponenten steigt, “skaliert das System über die Hardware- und Software”.

Wir hoffen, damit die wichtigsten Lasttest-Arten ein wenig beleuchtet zu haben.

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.

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.

Was ist ein Visits?

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

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

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

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

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

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

Was ist ein Pageview?

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

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

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

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

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

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

Fazit

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

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

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.

if(8 < 3)
{
    display.setIndex(1, 8);
}

Aber wer weiss, manchmal werden Sachen einfach true.

Ab sofort gibt es Hammerhead als neues und nützliches Firefox/Firebug-Plugin. Hammerhead misst die Ladezeit einer Webseite und zeigt sie übersichtlich in der Browser-Statusbar an. Zusätzlich erlaubt das Plugin ein Browser-Cachemanagement, um die Messungen zu verbessern bzw. Cache-Einflüsse auszuschliessen.