Those who are familiar with the Gomez load testing methodology have heard the terms “throughput” and “concurrency” mentioned often. Throughput and concurrency tests are the cornerstone of the Gomez load testing methodology, and when used properly can drastically reduce testing time and costs. The differences in how these tests are configured in our Reality Load solution are minimal, but the differences in how they are utilized and the results they produce are significant. It is critical to understand the difference between these two types of tests, and how they can be used to effectively and efficiently test the performance of your web application.
Let’s look at definitions for the terms concurrency and throughput and see how they apply to performance/load testing.
In relation to load/performance testing, throughput refers to the rate in which a web application can process raw data, full pages, or entire transactions.
With a “throughput test” you are aiming to stress the throughput of the web application. The throughput of a web application is usually measured by pages per second, objects/hits per second, or by transactions per minute.
When applied to the Web and web applications, concurrency is the measure of how many simultaneous user sessions are active on a web application at a given point of time.
In a “concurrency test” you’re trying to test how many concurrent user sessions a web application can support. In Reality Load, this is signified by the total number of virtual users that are active during a test.
At the very core, virtually the only difference between a throughput test and a concurrency test is the length of the user sessions. In Reality Load, session length is controlled by the “think time” – a time delay that is added into test scripts to simulate the pacing of real users using a web application – within a script.
Try to imagine how a real person behaves when visiting a website or page when thinking about “think time”. Most users are going to pause and scan the content that has just been displayed after a page has finished loading in the web browser and before they decide to click on a link or leave the site. Let’s say the page contains a form: Real users will typically require some time to fill in that form before they can submit it. This user processing time between page requests is what “think time” tries to emulate.
In my next post, I’ll discuss how to apply “Think Time” to a load test as an effective way of simulating real user behavior, but it is also an effective means for controlling the length of a user session.