From 30561f57be0c9b386ce05ccc9faf13c51218de4c Mon Sep 17 00:00:00 2001 From: Heitor Tashiro Sergent Date: Wed, 14 Feb 2024 14:11:51 -0300 Subject: [PATCH] chore: add redirects to load test types pages (#1509) --- gatsby-node.js | 36 +++++ .../en/06 Test Types/00 Load test types.md | 91 +------------ .../en/06 Test Types/01 Smoke Testing.md | 80 +---------- .../en/06 Test Types/02 Load Testing.md | 106 +-------------- .../en/06 Test Types/05 Soak Testing.md | 97 +------------- .../en/06 Test Types/06-spike-testing.md | 90 +------------ .../en/06 Test Types/07-breakpoint-testing.md | 124 +----------------- 7 files changed, 42 insertions(+), 582 deletions(-) diff --git a/gatsby-node.js b/gatsby-node.js index 51c5590922..a8b7e2b10d 100644 --- a/gatsby-node.js +++ b/gatsby-node.js @@ -1368,12 +1368,48 @@ const createRedirects = ({ actions }) => { isPermanent: true, }); + createRedirect({ + fromPath: '/test-types/load-test-types/', + toPath: 'https://grafana.com/load-testing/types-of-load-testing/', + isPermanent: true, + }); + + createRedirect({ + fromPath: '/test-types/smoke-testing/', + toPath: 'https://grafana.com/blog/2024/01/30/smoke-testing/', + isPermanent: true, + }); + + createRedirect({ + fromPath: '/test-types/load-testing/', + toPath: 'https://grafana.com/blog/2024/01/30/average-load-testing/', + isPermanent: true, + }); + createRedirect({ fromPath: '/test-types/stress-testing/', toPath: 'https://grafana.com/blog/2024/01/30/stress-testing/', isPermanent: true, }); + createRedirect({ + fromPath: '/test-types/soak-testing/', + toPath: 'https://grafana.com/blog/2024/01/30/soak-testing/', + isPermanent: true, + }); + + createRedirect({ + fromPath: '/test-types/spike-testing/', + toPath: 'https://grafana.com/blog/2024/01/30/spike-testing/', + isPermanent: true, + }); + + createRedirect({ + fromPath: '/test-types/breakpoint-testing/', + toPath: 'https://grafana.com/blog/2024/01/30/breakpoint-testing/', + isPermanent: true, + }); + createRedirect({ fromPath: '/cloud/cloud-faq/release-notes/', toPath: '/cloud/cloud-reference/release-notes/', diff --git a/src/data/markdown/translated-guides/en/06 Test Types/00 Load test types.md b/src/data/markdown/translated-guides/en/06 Test Types/00 Load test types.md index 25cf5c9686..375ad8a7d9 100644 --- a/src/data/markdown/translated-guides/en/06 Test Types/00 Load test types.md +++ b/src/data/markdown/translated-guides/en/06 Test Types/00 Load test types.md @@ -1,93 +1,4 @@ --- title: 'Load test types' -head_title: 'Understanding the Different Types of Load Tests: Goals and Recommendations' -excerpt: 'A series of conceptual articles explaining the different types of load tests. Learn about planning, running, and interpreting different tests for different performance goals.' -canonicalUrl: https://grafana.com/load-testing/types-of-load-testing/ +redirect: https://grafana.com/load-testing/types-of-load-testing/ --- - -Many things can go wrong when a system is under load. -The system must run numerous operations simultaneously and respond to different requests from a variable number of users. -To prepare for these performance risks, teams use load testing. - -But a good load-testing strategy requires more than just executing a single script. -Different patterns of traffic create different risk profiles for the application. -For comprehensive preparation, teams must test the system against different _test types_. - -![Overview of load test shapes](./images/chart-load-test-types-overview.png) - -## Different tests for different goals - -Start with smoke tests, then progress to higher loads and longer durations. - -The main types are as follows. Each type has its own article outlining its essential concepts. - -- [**Smoke tests**](/test-types/smoke-testing) validate that your script works and that the system performs adequately under minimal load. - -- [**Average-load test**](/test-types/load-testing) assess how your system performs under expected normal conditions. - -- [**Stress tests**](/test-types/stress-testing) assess how a system performs at its limits when load exceeds the expected average. - -- [**Soak tests**](/test-types/soak-testing) assess the reliability and performance of your system over extended periods. - -- [**Spike tests**](/test-types/spike-testing) validate the behavior and survival of your system in cases of sudden, short, and massive increases in activity. - -- [**Breakpoint tests**](/test-types/breakpoint-testing) gradually increase load to identify the capacity limits of the system. - -
- -In k6 scripts, configure the load configuration using [`options`](/get-started/running-k6/#using-options) or [`scenarios`](/using-k6/scenarios). This separates workload configuration from iteration logic. - -
- -## Test-type cheat sheet - -The following table provides some broad comparisons. - -| Type | VUs/Throughput | Duration | When? | -|------------|-----------------------|----------------------------|------------------------------------------------------------------------------------------------------------------| -| [Smoke](/test-types/smoke-testing) | Low | Short (seconds or minutes) | When the relevant system or application code changes. It checks functional logic, baseline metrics, and deviations | -| [Load](/test-types/load-testing) | Average production | Mid (5-60 minutes) | Often to check system maintains performance with average use | -| [Stress](/test-types/stress-testing) | High (above average) | Mid (5-60 minutes) | When system may receive above-average loads to check how it manages | -| [Soak](/test-types/soak-testing) | Average | Long (hours) | After changes to check system under prolonged continuous use | -| [Spike](/test-types/spike-testing) | Very high | Short (a few minutes) | When the system prepares for seasonal events or receives frequent traffic peaks | -| [Breakpoint](/test-types/breakpoint-testing) | Increases until break | As long as necessary | A few times to find the upper limits of the system | - - -## General recommendations - -When you write and run different test types in k6, consider the following. - -### Start with a smoke test - -Start with a [smoke test](/test-types/smoke-testing). -Before beginning larger tests, validate that your scripts work as expected and that your system performs well with a few users. - -After you know that the script works and the system responds correctly to minimal load, -you can move on to average-load tests. -From there, you can progress to more complex load patterns. - -### The specifics depend on your use case - -Systems have different architectures and different user bases. As a result, the correct load testing strategy is highly dependent on the risk profile for your organization. Avoid thinking in absolutes. - -For example, k6 can model load by either number of VUs or by number of iterations per second ([open vs. closed](https://k6.io/docs/using-k6/scenarios/concepts/open-vs-closed/)). -When you design your test, consider which pattern makes sense for the type. - -What's more, **no single test type eliminates all risk.** -To assess different failure modes of your system, incorporate multiple test types. -The risk profile of your system determines what test types to emphasize: -- Some systems are more at risk of longer use, in which case soaks should be prioritized. -- Others are more at risk of intensive use, in which case stress tests should take precedence. - -In any case, **no single test can uncover all issues**. - -What's more, the categories themselves are relative to use cases. A stress test for one application is an average-load test for another. Indeed, no consensus even exists about the names of these test types (each of the following topics provides alternative names). - -### Aim for simple designs and reproducible results - -While the specifics are greatly context-dependent, what's constant is that you want to make results that you can compare and interpret. - -Stick to simple load patterns. For all test types, directions is enough: ramp-up, plateau, ramp-down. - -Avoid "rollercoaster" series where load increases and decreases multiple times. These will waste resources and make it hard to isolate issues. - diff --git a/src/data/markdown/translated-guides/en/06 Test Types/01 Smoke Testing.md b/src/data/markdown/translated-guides/en/06 Test Types/01 Smoke Testing.md index 203d94fa59..3a80b0cfbe 100644 --- a/src/data/markdown/translated-guides/en/06 Test Types/01 Smoke Testing.md +++ b/src/data/markdown/translated-guides/en/06 Test Types/01 Smoke Testing.md @@ -1,82 +1,4 @@ --- title: "Smoke testing" -head_title: 'What is Smoke Testing? How to create a Smoke Test in k6' -excerpt: "A Smoke test is a minimal load test to run when you create or modify a script." -canonicalUrl: https://grafana.com/blog/2024/01/30/smoke-testing/ +redirect: https://grafana.com/blog/2024/01/30/smoke-testing/ --- - -Smoke tests have a minimal load. -Run them to verify that the system works well under minimal load and to gather baseline performance values. - -This test type consists of running tests with a few VUs — more than 5 VUs could be considered a mini-load test. - -Similarly, the test should execute for a short period, either a low number of [iterations](/using-k6/k6-options/reference/#iterations) or a [duration](/using-k6/k6-options/reference/#duration) from seconds to a few minutes maximum. - -![Overview of a smoke test](images/chart-smoke-test-overview.png) - -In some testing conversation, smoke tests are also called shakeout tests. - -## When to run a Smoke test - -Teams should run smoke tests whenever a test script is created or updated. Smoke testing should also be done whenever the relevant application code is updated. - -It's a good practice to run a smoke test as a first step, with the following goals: - -- Verify that your test script doesn't have errors. -- Verify that your system doesn't throw any errors (performance or system related) when under minimal load. -- Gather baseline performance metrics of your system’s response under minimal load. -- With simple logic, to serve as a synthetic test to monitor the performance and availability of production environments. - -## Considerations - -When you prepare a smoke test, consider the following: - - -- **Each time you create or update a script, run a smoke test** - - Because smoke tests verify test scripts, try to run one every time you create or update a script. Avoid running other test types with untested scripts. - -- **Keep throughput small and duration short** - - Configure your test script to be executed by a small number of VUs (from 2 to 20) with few iterations or brief durations (30 seconds to 3 minutes). - -## Smoke testing in k6 - - - -```javascript -import http from 'k6/http'; -import { check, sleep} from 'k6'; - -export const options = { - vus: 3, // Key for Smoke test. Keep it at 2, 3, max 5 VUs - duration: '1m', // This can be shorter or just a few iterations -}; - -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. -}; -``` - - - - -The following script is an example smoke test. You can copy it, change the endpoints, and start testing. For more comprehensive test logic, refer to [Examples](/examples). -The VU chart of a smoke test should look similar to this. - -![The shape of the smoke test as configured in the preceding script](images/chart-smoke-test-k6-script-example.png) - -## Results analysis - -The smoke test initially validates that your script runs without errors. If any script-related errors appear, correct the script before trying any more extensive tests. - -On the other hand, if you notice poor performance with these low VU numbers, report it, fix your environment, and try again with a smoke test before any further tests. - -Once your smoke test shows zero errors and the performance results seem acceptable, you can proceed to other test types. - diff --git a/src/data/markdown/translated-guides/en/06 Test Types/02 Load Testing.md b/src/data/markdown/translated-guides/en/06 Test Types/02 Load Testing.md index ebc3b8e991..9c304588c5 100644 --- a/src/data/markdown/translated-guides/en/06 Test Types/02 Load Testing.md +++ b/src/data/markdown/translated-guides/en/06 Test Types/02 Load Testing.md @@ -1,108 +1,4 @@ --- title: 'Load testing' -head_title: 'What is Load Testing? How to create a Load Test in k6' -excerpt: 'An average load test assesses the performance of your system in terms of concurrent users or requests per second.' -canonicalUrl: https://grafana.com/blog/2024/01/30/average-load-testing/ +redirect: https://grafana.com/blog/2024/01/30/average-load-testing/ --- - -An average-load test assesses how the system performs under typical load. Typical load might be a regular day in production or an average moment. - -Average-load tests simulate the number of concurrent users and requests per second that reflect average behaviors in the production environment. This type of test typically increases the throughput or VUs gradually and keeps that average load for some time. Depending on the system's characteristics, the test may stop suddenly or have a short ramp-down period. - -![Overview of an average load test](images/chart-average-load-test-overview.png) - -Since “load test” might refer to all types of tests that simulate traffic, this guide uses the name _average-load test_ to avoid confusion. -In some testing conversation, this test also might be called a day-in-life test or volume test. - -## When to run an average load test - -Average-Load testing helps understand whether a system meets performance goals on a typical day (commonplace load). _Typical day_ here means when an average number of users access the application at the same time, doing normal, average work. - -You should run an average load test to: - -* Assess the performance of your system under a typical load. -* Identify early degradation signs during the ramp-up or full load periods. -* Assure that the system still meets the performance standards after system changes (code and infrastructure). - -## Considerations - -When you prepare an average-load test, consider the following: - -* **Know the specific number of users and the typical throughput per process in the system.** - - To find this, look through APMs or analytic tools that provide information from the production environment. If you can't access such tools, the business must provide these estimations. -* **Gradually increase load to the target average.** - - That is, use a _ramp-up period_. This period usually lasts between 5% and 15% of the total test duration. A ramp-up period has many essential uses: - * It gives your system time to warm up or auto-scale to handle the traffic. - * It lets you compare response times between the low-load and average-load stages. - * If you run tests using our cloud service, a ramp up lets the automated performance alerts understand the expected behavior of your system. - -* **Maintain average for a period longer than the ramp up.** - - Aim for an average duration at least five times longer than the ramp-up to assess the performance trend over a significant period of time. - -* **Consider a ramp-down period.** - - The ramp down is when virtual user activity gradually decreases. The ramp down usually lasts as long as the ramp up or a bit less. - -## Average-load testing in k6 - -
- -If this is your first time running load tests, we recommend starting small or configuring the ramp-up to be slow. Your application and infrastructure might not be as rock solid as you think. We've had thousands of users run load tests that quickly crash their applications (or staging environments). - -
- -The goal of an average-load test is to simulate the average amount of activity on a typical day in production. The pattern follows this sequence: - -1. Increase the script's activity until it reaches the desired number of users and throughput. -1. Maintain that load for a while -1. Depending on the test case, stop the test or let it ramp down gradually. - -Configure load in the `options` object: - - - -```javascript -import http from 'k6/http'; -import {sleep} from 'k6'; - -export const options = { - // Key configurations for avg load test in this section - stages: [ - { duration: '5m', target: 100 }, // traffic ramp-up from 1 to 100 users over 5 minutes. - { duration: '30m', target: 100 }, // stay at 100 users for 30 minutes - { 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. -}; -``` - - - - -This script logic has only one request (to open a web page). Your test behavior likely has more steps. If you would like to see more complex tests that use groups, checks, thresholds, and helper functions, refer to [Examples](/examples). - -The VU or throughput chart of an average-load test looks similar to this: - -![The shape of the average-load test as configured in the preceding script](images/chart-average-load-test-k6-script-example.png "Note that the number of users or throughput starts at 0, gradually ramps up to the desired value, and stays there for the indicated period. Then load ramps down for a short period." ) - - -## Results analysis - -An initial outcome for the average-load test appears during the ramp-up period to find whether the response time degrades as the load increases. Some systems might even fail during the ramp-up period. - -The test validates if the system's performance and resource consumption stay stable during the period of full load, as some systems may display erratic behavior in this period. - -Once you know your system performs well and survives a typical load, you may need to push it further to determine how it behaves at above-average conditions. Some of these above-average conditions are known as [Stress tests](/test-types/stress-testing). - diff --git a/src/data/markdown/translated-guides/en/06 Test Types/05 Soak Testing.md b/src/data/markdown/translated-guides/en/06 Test Types/05 Soak Testing.md index dfaf04bc67..fcdd6650d2 100644 --- a/src/data/markdown/translated-guides/en/06 Test Types/05 Soak Testing.md +++ b/src/data/markdown/translated-guides/en/06 Test Types/05 Soak Testing.md @@ -1,99 +1,4 @@ --- title: 'Soak testing' -head_title: 'What is Soak Testing? How to create a Soak Test in k6' -excerpt: 'A Soak Test tests the reliability and performance of your system over extended periods of use.' -canonicalUrl: https://grafana.com/blog/2024/01/30/soak-testing/ +redirect: https://grafana.com/blog/2024/01/30/soak-testing/ --- - -Soak testing is another variation of 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 and 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. - -![Overview of a soak test](images/chart-soak-test-overview.png) - -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 test type checks for common performance defects that show only 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, consider the following: - -* **Configure the duration to be considerably longer than any other test.** - - Some typical values are 3, 4, 8, 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 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. -1. Maintain that load for **a considerably longer time.** -1. 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, refer to [Examples](/examples). - -Notice that, as in an average-load test, peak load plateaus at 100. VUs. -The difference is in duration. -In this soak, peak load maintains for 8 hours rather than some minutes. - -![The shape of the soak test as configured in the preceding script](images/chart-soak-test-k6-script-example.png) - -## Results analysis - -If we execute this test after the previous types, we should have a system performing well under previous scenarios. In this test, monitor for changes in any performance metric 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 (improvements, too) in response time and backend hardware resources. Backend resources to check are RAM consumed, CPU, Network, and 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. - -After you run all the previous test types, you know your system performs well at many different loads: small, average, high, and extended. - diff --git a/src/data/markdown/translated-guides/en/06 Test Types/06-spike-testing.md b/src/data/markdown/translated-guides/en/06 Test Types/06-spike-testing.md index 740e4712ef..8042b61310 100644 --- a/src/data/markdown/translated-guides/en/06 Test Types/06-spike-testing.md +++ b/src/data/markdown/translated-guides/en/06 Test Types/06-spike-testing.md @@ -1,92 +1,4 @@ --- title: 'Spike testing' -excerpt: 'Spike tests simulate moments of short, extreme load' -canonicalUrl: https://grafana.com/blog/2024/01/30/spike-testing/ +redirect: https://grafana.com/blog/2024/01/30/spike-testing/ --- - -A spike test verifies whether the system survives and performs under sudden and massive rushes of utilization. - -Spike tests are useful when the system may experience events of sudden and massive traffic. -Examples of such events include ticket sales (Taylor Swift), product launches (PS5), broadcast ads (Super Bowl), process deadlines (tax declaration), and seasonal sales (Black Friday). Also, spikes in traffic could be caused by more frequent events such as rush hours, a particular task, or a use case. - -Spike testing increases to extremely high loads in a very short or non-existent ramp-up time. -Usually, it has no plateau period or is very brief, as real users generally do not stick around doing extra steps in these situations. In the same way, the ramp-down is very fast or non-existent, letting the process iterate only once. - -This test might include different processes than the previous test types, as spikes often aren't part of an average day in production. It may also require adding, removing, or modifying processes on the script that were not in the average-load tests. - -Occasionally, teams should revamp the system to allow or prioritize resources for the high-demand processes during the event. - -![Overview of a spike test](images/chart-spike-test-overview.png) - -## When to perform a spike test - -This test must be executed when the system expects to receive a sudden rush of activity. - - -When the system expects this type of behavior, the spike test helps identify how the system will behave and if it will survive the sudden rush of load. The load is considerably above the average and might focus on a different set of processes than the other test types. - - -## Considerations - -When preparing for a spike test, consider the following: - -* **Focus on key processes in this test type.** - - Assess whether the spike in traffic triggers the same or different processes from the other test types. Create test logic accordingly. -* **The test often won't finish.** - - Errors are common under these scenarios. -* **Run, tune, repeat.** - - When your system is at risk of spike events, the team must run a spikes test and tune the system several times. -* **Monitor.** - - Backend monitoring is a must for successful outcomes of this test. - -## Spike testing in k6 - -The key differentiators of the spike test are the simulation of sudden and very high loads. It lacks a plateau (full load) duration or is usually brief. - -Sometimes, the test may require a load plateau for some time. If a plateau is needed, it's generally short. A ramp-down can also be quick or unnecessary as the goal is to suddenly increase the system's load. - - - -```javascript -import http from 'k6/http'; -import {sleep} from 'k6'; - -export const options = { - // Key configurations for spike in this section - stages: [ - { duration: '2m', target: 2000 }, // fast ramp-up to a high point - // No plateau - { duration: '1m', target: 0 }, // quick ramp-down to 0 users - ], -}; - -export default () => { - const urlRes = http.get('https://test-api.k6.io'); - sleep(1); - // MORE STEPS - // Add only the processes that will be on high demand - // Step1 - // Step2 - // etc. -}; -``` - - - -In a spike test, load quickly increases to an extreme level. -The ramp-down period follows when the test reaches the maximum, returning to 0 quickly. - -A spike test gets its name from the shape of its load when represented graphically. - -![The shape of the spike test as configured in the preceding script](images/chart-spike-test-k6-script-example.png "Note that the load goes from 0 to peak in three minutes: an abrupt increase.") - -## Results analysis - -Some performance metrics to assess in spike tests include pod speeds, recovery times after the load rush, time to return to normal, or the behavior on crucial system processes during the overload. - -Finding how the system responds (if it survives) to the sudden rush helps to optimize it to guarantee that it can perform during a real event. In some events, the load is so high that the whole system may have to be optimized to deal with the key processes. In these cases, repeat the test until the system confidence is high. - diff --git a/src/data/markdown/translated-guides/en/06 Test Types/07-breakpoint-testing.md b/src/data/markdown/translated-guides/en/06 Test Types/07-breakpoint-testing.md index 1dc1db8556..26f4218bba 100644 --- a/src/data/markdown/translated-guides/en/06 Test Types/07-breakpoint-testing.md +++ b/src/data/markdown/translated-guides/en/06 Test Types/07-breakpoint-testing.md @@ -1,126 +1,4 @@ --- title: 'Breakpoint testing' -excerpt: 'Breakpoint tests aim to find system limits. They increase load until the system fails.' -canonicalUrl: https://grafana.com/blog/2024/01/30/breakpoint-testing/ +redirect: https://grafana.com/blog/2024/01/30/breakpoint-testing/ --- - -Breakpoint testing aims to find system limits. Reasons you might want to know the limits include: - -* To tune or care for the system's weak spots to relocate those higher limits at higher levels. -* To help plan remediation steps in those cases and prepare for when the system nears those limits. - -In other words, knowing where and how a system starts to fail helps prepare for such limits. - - -A breakpoint ramps to unrealistically high numbers. -This test commonly has to be stopped manually or automatically as thresholds start to fail. When these problems appear, the system has reached its limits. - -![Overview of a breakpoint test](images/chart-breakpoint-test-overview.png) - -The breakpoint test is another test type with no clear naming consensus. -In some testing conversation, it's also known as capacity, point load, and limit testing. - -## When to run a breakpoint test - -Teams execute a breakpoint test whenever they must know their system's diverse limits. Some conditions that may warrant a breakpoint test include the following: - -* The need to know if the system's load expects to grow continuously -* If current resource consumption is considered high -* After significant changes to the code-base or infrastructure. - -How often to run this test type depends on the risk of reaching the system limits and the number of changes to provision infrastructure components. - -Once the breakpoint runs and the system limits have been identified, you can repeat the test after the tuning exercise to validate how it impacted limits. Repeat the test-tune cycle until the team is satisfied. - -## Considerations - -* **Avoid breakpoint tests in elastic cloud environments.** - - The elastic environment may grow as the test moves further, finding only the limit of your cloud account bill. If this test runs on a cloud environment, **turning off elasticity on all the affected components is strongly recommended**. -* **Increase the load gradually.** - - A sudden increase may make it difficult to pinpoint why and when the system starts to fail. - -* **System failure could mean different things to different teams** - - You might want to identify each of the following failure points: - * Degraded performance. The response times increased, and user experience decreased. - * Troublesome performance. The response times get to a point where the user experience severely degrades. - * Timeouts. Processes are failing due to extremely high response times. - * Errors. The system starts responding with HTTP error codes. - * System failure. The system collapsed. - -* **You can repeat this test several times** - - Repeating after each tuning might let the you push the system further. - -* **Run breakpoints only when the system is known to perform under all other test types.** - - The breakpoint test might go far if the system performs poorly with the previous testing types. - -## Breakpoint testing in k6 - -The breakpoint test is straightforward. Load slowly ramps up to a considerably high level. -It has no plateau, ramp-down, or other steps. And it generally fails before reaching the indicated point. - -k6 offers two ways to increase the activity: increasing VUs or increasing throughput ([open and closed models](/using-k6/scenarios/concepts/open-vs-closed/)). -Different from other load test types, which should be stopped when the system degrades to a certain point, breakpoint load increases even as the system starts to degrade. -That makes it recommendable to use [ramping-arrival-rate](/using-k6/scenarios/executors/ramping-arrival-rate/) for a breakpoint test. - -The test keeps increasing load or VUs until it reaches the defined breaking point or system limits, at which point the test stops or is aborted. - - - -```javascript -import http from 'k6/http'; -import {sleep} from 'k6'; - -export const options = { - // Key configurations for breakpoint in this section - executor: 'ramping-arrival-rate', //Assure load increase if the system slows - stages: [ - { duration: '2h', target: 20000 }, // just slowly ramp-up to a HUGE load - ], -}; - -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. -}; -``` - - - -![The shape of the breakpoint test as configured in the preceding script](images/chart-breakpoint-test-k6-script-example.png) - -The test must be stopped before it completes the scheduled execution. -You can stop the test manually or with a threshold: -- To stop k6 manually in the CLI, press `Ctrl+C` in Linux or Windows, and `Command .` in Mac. -- To stop the test using a threshold, you must define `abortOnFail` as true. -For details, refer to the [Thresholds ](https://k6.io/docs/using-k6/thresholds/). - -## Results analysis - -A breakpoint test must cause system failure. -The test helps identify the failure points of our system and how the system behaves once it reaches its limits. - -Once the system limits are identified, the team has two choices: accept them or tune the system. - -If the decision is to accept the limits, the test results help teams prepare and act when the system is nearing such limits. - -These actions could be: - -* Prevent reaching such limits -* Grow system resources -* Implement corrective actions for the system behavior at its limit -* Tune the system to stretch its limits - -If the action taken is to tune the system, tune, then repeat the breakpoint test to find where and whether the system limits moved. - -A team must determine the number of repetitions of the breakpoint test, how much the system can be tuned, and how far its limits can be tuned after each exercise. -