SoapUI Load Strategies

 

The different Load Strategies available in SoapUI and SoapUI Pro allow you to simulate various types of load over time. Further, this enables you to easily test the performance of your target services under a number of conditions. Since SoapUI also allows you to run multiple LoadTests simultaneously, a combination of LoadTests can be used to further assert the behavior of your services. Therefore, select the desired Strategy for your LoadTest from the Strategy Toolbar in the LoadTest Window:

SoapUI Load Strategies: Simple Strategy – Baseline, Load and Soak Testing

The Simple Strategy runs the specified number of threads with the specified delay between each run to simulate a breathing space for the server. Further, the Simple Strategy is perfect for Baseline testing. So, use it to assert the basic performance of your service. Also, validate that there are no threading or resource locking issues. Now, ramp up the number of threads and use the strategy for long-running soak tests.

SoapUI Load Strategies: Fixed Rate Strategy

The Simple Strategy doesn’t guarantee a number of executions within a certain time. The “Request Level” setting will attempt to maintain the TPS on the request level instead. For instance, if you have a data-driven LoadTest or a TestCase with many requests. Then, you want the TPS setting to apply not on the execution level of the entire TestCase but on the request level.

In any case, the Fixed Rate strategy is useful for baseline, load and soak-testing if you don’t run into the “Thread Congestion” problem described above. On the other hand, you might provoke the congestion (maybe even in combination with another LoadTest) to see how your services handle this or how they recover after the congestion has been handled.

Variable Load Strategies

There are several strategies that can be used to vary load (the number of threads) over time, each simulating a different kind of behavior. They can be useful for recovery and stress testing, but just as well for baseline testing, either on their own or in combination with other strategies.

Running this with the strategy interval set to 5000 the number of threads will change every 5 seconds:

Variance Strategy

this varies the number of threads over time in a “sawtooth” manor as configured; set the Interval to the desired value and the Variance to the how much the number of threads should decrease and increase.

Burst Strategy

This strategy is specifically designed for Recovery Testing and takes variance to its extreme. It does nothing for the configured Burst Delay, then runs the configured number of threads for the “Burst Duration” and goes back to sleep. Here you could (and should!) set the number of threads to a high value (20+) to simulate an onslaught of traffic during a short interval. Then, measure the recovery of your system with a standard base-line LoadTest containing basic performance-related assertions. Let’s try this with a burst delay and duration of 10 seconds for 60 seconds:

Grid Strategy –

This strategy allows the user to specifically configure the relative change in the number of threads over a defined interval of time. Further, its main use for this is a more advanced scenario and recovery testing, where you need to see the service’s behavior under varying loads and load changes.

Both values are stored relative to the duration and actual ThreadCount of the LoadTest. If you change these, the corresponding Grid Strategy values will be recalculated. Running the test shows the following output:

Script Strategy

The script strategy is the ultimate customization possibility. The script you specify is called regularly and should return the desired number of threads. However, returning a value other than the current one will start or stop threads to adjust for the change. Further, this allows for any kind of variance of the number of threads. So, for instance, the following script randomizes the number of threads between 5 and 15

Statistics Calculation and ThreadCount Changes

Many of these strategies will change the number of threads which has an important impact on the statistics calculation. Further, you need to be aware of when the number of threads changes. This will usually change the response times of the target services, resulting in a change in avg, tps, etc. But, the LoadTest has already run at a previous number of threads the results for those runs will skew the result for the new ThreadCount.

Make your resume stand out and become a Certified SoapUI Testing Professional. Try free practice tests here!

A great career is just a certification away. So, practice and validate your skills to become a Certified SoapUI Testing Professional.