When you want to determine the ultimate load of a system, the JMeter Arrivals Thread Group allows the test designer to set a rate by which the load test will continuously increase requests. By extension, this component is also useful in certain cases where it is desirable to increase request rates exponentially.
In a previous post we outlined the various plugins in the Custom Thread Groups package for JMeter. In addition to the most commonly used thread groups in this package, the Arrivals Thread Group and the Free-Form Arrivals Thread Group are two components that have particular behavior and niche use cases. In this post, we will explore how these thread groups behave and give example cases ‒ and show you how the they can be useful in your load tests.
Traditionally when we create a load test that will prove the ultimate load of a system, it involves a series of test runs that probe ever-increasing levels of concurrency until a breaking point is achieved. We may use ramp-up features of the Stepping Thread Group or the Ultimate Thread Group to generate a range of throughputs for our test. However, at the end of each test we can expect no more than a finite load that is either met or drives our target test application to its breaking point.
The Arrivals Thread Group fundamentally differs from ordinary thread groups as it allows the test designer to set a rate by which the load test will continuously increase requests. This enables us to easily define an ever-increasing concurrency for the duration of our test.
In the above example we have created a test which will start threads at first exponentially for the first two minutes of the test, then linearly increasing this load over the next 19 minutes. At the conclusion of the test we can expect 10,000 instantaneous concurrent requests to be arriving at our target test endpoint. Setting a test up using the Arrivals Thread Group allows us to exponentially increase our throughput simply by lengthening the duration of the test.
There is also a version of this plugin called the Free-Form Arrivals Thread Group, which allows even greater control over the request rates over time. For comparison, we can reproduce the above test by entering the following data into the Threads Schedule table:
If you are familiar with how to create a Threads Schedule with the related Ultimate Thread Group plugin, creating a thread profile works in much the same way. However, instead of directly defining thresholds, we are defining rates of requests. Consider the following different example:
In this slightly more complex test, over the course of one hour we are directing traffic in a series of increasing “waves”. This test simulates the behavior of cohorts of users accessing a target test application intermittently. As with the previous examples, the rate at which new requests are generated is held constant. Therefore, the longer the period at each plateau in our request profile, the more simultaneous simulated users will reach the defined endpoints in our test. This makes it easy to exponentially increase the size of each cohort of users simply by extending the length of each plateau.
Did you know that RedLine13 offers a time-limited full-featured free trial? Sign up now and start testing today!