Help build the future of open source observability software Open positions

Check out the open source projects we support Downloads

Grot cannot remember your choice unless you click the consent notice at the bottom.

Soak testing: A beginner's guide

Soak testing: A beginner's guide

January 30, 2024 4 min

This content was originally published on k6.io.
30 Jan 2024

Soak testing is another variation of load testing that is similar to the average-load test. It focuses on extended periods, analyzing the following:

  • The system’s degradation of performance and resource consumption over extended periods.
  • The system’s availability and stability during extended periods.

The soak test differs from an average-load test in test duration. In a soak test, the peak load duration (usually an average amount) extends several hours or even days. Though the duration is considerably longer, the ramp-up and ramp-down periods of a soak test are the same as an average-load test.

Soak test chart in Grafana k6.

In some testing conversation, a soak test might be called an endurance, constant high load, or stamina test.

When to perform a soak test

Most systems must stay turned on and keep working for days, weeks, and months without intervention. This test verifies the system stability and reliability over extended periods of use.

This type of load testing checks for common performance defects that only show after extended use. Those problems include response time degradation, memory or other resource leaks, data saturation, and storage depletion.

Considerations

When you prepare to run a soak test, take into account the following considerations:

  • Configure the duration to be considerably longer than any other test. Some typical values are three, four, eight, 12, 24, and 48 to 72 hours.
  • If possible, re-use the average-load test script.
    Changing only the peak durations for the aforementioned values.
  • Don’t run soak tests before running smoke and average-load tests.
    Each test uncovers different problems. Running this first may cause confusion and resource waste.
  • Monitor the backend resources and code efficiency.
    Since we are checking for system degradation, monitoring the backend resources and code efficiency is highly recommended. Of all test types, backend monitoring is especially important for soak tests.

Soak testing in Grafana k6

The soak test is almost the same as the average-load test. The only difference is the increased duration of the load plateau.

  1. Increase the load until it reaches an average number of users or throughput.
  2. Maintain that load for a considerably long time.
  3. Finally, depending on the test case, stop or ramp down gradually.

Configure the load duration in the options object:

JavaScript
import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  // Key configurations for Soak test in this section
  stages: [
    { duration: '5m', target: 100 }, // traffic ramp-up from 1 to 100 users over 5 minutes.
    { duration: '8h', target: 100 }, // stay at 100 users for 8 hours!!!
    { duration: '5m', target: 0 }, // ramp-down to 0 users
  ],
};

export default () => {
  const urlRes = http.get('https://test-api.k6.io');
  sleep(1);
  // MORE STEPS
  // Here you can have more steps or complex script
  // Step1
  // Step2
  // etc.
};

For more complex behavior, you can refer to more load testing examples in our k6 documentation.

Notice that, as in an average-load test, peak load plateaus at 100 VUs. The difference in a soak test is in duration. In this soak, peak load maintains for eight hours rather than a few minutes.

Soak test chart for an 8-hour duration in Grafana k6.

Soak test results: analysis

If we execute this test after smoke tests and average-load tests, we should have a system performing well under previous scenarios. In this test, monitor for changes in any performance metrics as time passes. Try to correlate any impact with backend measurement changes that indicate degradation over time. Such changes can be gradual degradations, as mentioned, and sudden changes (or improvements, too) in response time and backend hardware resources. Backend resources to check are RAM consumed, CPU, network, growth of cloud resources, among others.

The expected outcome is that the performance and resource utilization of the backend stays stable or within expected variations over extended periods of time.

Grafana Cloud is the easiest way to get started with Grafana k6 and performance testing. We have a generous forever-free tier and plans for every use case. Sign up for free now!