断点测试
断点测试旨在找出系统限制。您可能希望了解这些限制的原因包括:
- 调优或关注系统的薄弱环节,以将这些限制提高到更高的水平。
- 帮助规划这些情况下的补救措施,并为系统接近这些限制时做好准备。
换句话说,了解系统何时以及如何开始出现故障有助于为这些限制做好准备。
断点测试会将负载逐渐增加到不切实际的高水平。当阈值开始失效时,通常需要手动或自动停止此测试。当这些问题出现时,表明系统已达到其极限。
断点测试是另一种没有明确命名共识的测试类型。在一些测试讨论中,它也被称为容量测试、点负载测试和极限测试。
何时运行断点测试
团队在需要了解系统各种限制时会执行断点测试。可能需要进行断点测试的一些条件包括以下情况:
- 需要了解系统的负载是否会持续增长
- 当前资源消耗被认为很高时
- 代码库或基础设施发生重大变更后。
运行此类测试的频率取决于达到系统限制的风险以及配置基础设施组件的变更次数。
一旦断点测试运行并确定了系统限制,您可以在调优练习后重复测试,以验证其对限制的影响。重复测试-调优循环,直到团队满意为止。
注意事项
避免在弹性云环境中进行断点测试。
随着测试的深入,弹性环境可能会扩展,您只会找到云账户账单的上限。如果此测试在云环境中运行,强烈建议关闭所有受影响组件的弹性功能。
逐渐增加负载。
突然的增加可能难以确定系统何时以及为何开始出现故障。
系统故障对不同的团队可能意味着不同的事情
您可能需要识别以下每个故障点
- 性能下降。响应时间增加,用户体验变差。
- 棘手的性能问题。响应时间达到严重损害用户体验的程度。
- 超时。由于极高的响应时间,进程失败。
- 错误。系统开始响应 HTTP 错误代码。
- 系统崩溃。系统已无法运行。
您可以多次重复此测试
每次调优后重复测试可以帮助您进一步突破系统极限。
仅当已知系统在所有其他测试类型下均表现良好时,才运行断点测试。
如果系统在之前的测试类型中表现不佳,断点测试可能很快就会达到极限。
在 k6 中进行断点测试
断点测试非常直接。负载缓慢上升到相当高的水平。它没有高原期、下降期或其他阶段。并且它通常在达到指定点之前就会失败。
k6 提供两种增加活动的方法:增加 VU(虚拟用户)或增加吞吐量(开放模型和封闭模型)。与其他应在系统退化到一定程度时停止的负载测试类型不同,断点测试即使在系统开始退化时仍会增加负载。因此,建议在断点测试中使用递增到达率 (ramping-arrival-rate)。
测试会持续增加负载或 VU,直到达到定义的断裂点或系统限制,此时测试会停止或中止。
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://quickpizza.grafana.com');
sleep(1);
// MORE STEPS
// Here you can have more steps or complex script
// Step1
// Step2
// etc.
};
测试必须在完成计划执行之前停止。您可以手动停止测试或使用阈值停止测试
- 要在 CLI 中手动停止 k6,在 Linux 或 Windows 中按
Ctrl+C
,在 Mac 中按Command .
。 - 要使用阈值停止测试,必须将
abortOnFail
设置为 true。
有关详细信息,请参阅阈值。
结果分析
断点测试必须导致系统故障。该测试有助于识别系统的故障点以及系统达到极限后的行为方式。
一旦确定了系统限制,团队有两种选择:接受它们或调优系统。
如果决定接受这些限制,测试结果有助于团队在系统接近这些限制时做好准备并采取行动。
这些行动可以是
- 阻止达到这些限制
- 增加系统资源
- 对系统达到极限时的行为实施纠正措施
- 调优系统以扩展其极限
如果采取的行动是调优系统,则先进行调优,然后重复断点测试,以找出系统限制的位置以及是否发生了变化。
团队必须确定断点测试的重复次数、系统可以调优到什么程度以及每次练习后其极限可以调优到多远。