Every day, the efficiency of applications is put to the test. To ensure they will perform according to expected user experience standards, performance tests are routinely conducted. However, there are certain times of the year—such as Black Friday and Christmas for the retail value chain—when systems are pushed to their limits very quickly. To ensure they are prepared for these moments, we conduct peak-load tests.

Like load tests, peak tests determine the volume of connections and data transfer requests that the system can handle. The main difference is that, rather than evaluating components or systems gradually under low, typical, or high usage conditions, peak tests evaluate only the scenario of sudden, high usage.

In this article, we’ll explain peak testing in greater detail, highlighting its importance. In addition, we’ll show how it relates to stress and load testing, why it’s so crucial for annual application planning, and how to fit it into the schedule so that the results are available in time to address any issues that are found.

The Intersection of Load and Stress

Peak tests are used to determine a system’s ability to recover—and return to a stable state—after repeated bursts of load that push its operating level to its peak. Like load, endurance, and stress tests, peak tests are classified by the International Software Testing Qualifications Board as a type of performance test.

In the technical literature, peak tests fall at the intersection of load and stress tests, and are more closely related to the latter. It is common to find peak tests classified as a subtype of stress tests.

This is because the peaks are tested based on the Service Limit State and Ultimate Limit State indicators, which are determined in stress tests. In practice, this involves injecting a high volume of load into the applications, to the point where they reach their limit states within a very short period of time. Shortly thereafter, this load volume is also suddenly removed. Peak tests analyze the system’s behavior at both moments: when the load is injected and when it returns to its typical operating state.

In other words, one of the goals of peak testing is to determine the “actual” limit states—that is, under the most adverse scenario possible: a high volume of load over a very short period of time.

Just as in other performance tests, in peak tests we subject the applications—separately or together—to the three elements that characterize the load—which we explained in the post we published here on the blog about load testing:

• Concurrent users
• Requisitions
• Data Volume and Complexity

Each of them illustrates the behavior of a single dimension, and by analyzing them together, we can identify which ones contribute most to the rate of acceleration toward the peak and which ones most hinder the system’s recovery until it returns to its normal operating state.

Peak Testing: How We Identify Key Performance Metrics

In all types of performance tests, we analyze the same five metrics or variations thereof. In the case of peak tests, this is how we look at them:

1. Concurrent users → this is the variable that best represents a real-world scenario of peak traffic. In testing, it is by abruptly increasing the number of users that we determine how many concurrent sessions the application can handle before failing.
2. Response time → Analyzing it means focusing on the latency curve during the sudden surge in users—the rise toward the peak. Since the user experience is impacted during this phase, the goal is to determine how users perceive the slowness and what percentage of them give up.
3. Throughput → This refers to the point at which the application stops scaling and begins to queue or reject requests.
4. Resource consumption → The goal is to identify which resource is depleted first and how the depletion spreads. Most importantly, however, is to see how resources are released when the load drops and how long it takes for the application to return to normal.
5. Error rate → measures the proportion of requests that failed during peak traffic. A high error rate early on indicates that the actual Service Limit is lower than what the stress tests indicated, suggesting the need to review those tests.

Among all the benefits of peak testing, the most obvious is the protection of the company’s revenue and reputation when its applications are central to customer relationships. In retail, this is especially evident: going offline or experiencing slow performance on Black Friday or Christmas means losing sales and, in many cases, driving customers to competitors.

The second most obvious benefit is planning. The results of peak testing —in addition to showing how much infrastructure to provision for critical dates and which resources have the greatest impact on costs (especially when using cloud computing with a single server or in a multicloud model)—help determine which protection mechanisms to adopt. A classic example is the use of virtual queues in ticket sales for concerts and sports games: they limit the number of users who can access the system at the same time, so the application isn’t overloaded.

Peak-load tests conducted one week before Black Friday or Christmas are of little use. If they reveal a problem, there won’t be time to fix it. That’s why they need to be planned well in advance and scheduled on the calendar for the entire team responsible for the deployment.

In the Artificial Intelligence Operations Model we use here at Inmetrics, peak testing is particularly important in security analysis, as well as in performance and quality analysis—which are, respectively, part of the Challenge Identification and Solution phases of the Artificial Intelligence Operations Model. If, in addition to stress testing, you need to understand the limit states of your applications under the most adverse scenarios possible, click here to contact us! We can demonstrate real-world examples of application peak loads to clarify how your applications can be better protected during critical periods!