设置负载测试的基线

定义负载测试和阈值后，我们使用它们来生成基线。

基线是一组指标条件，用于评估测试是失败还是成功。 例如，条件可能是：

• 每秒平均请求数。
• 错误率。
• 最大响应时间。

若要设置负载测试的基线，需要执行以下操作：

1. 为各个用户流和整个解决方案定义基线和测试条件。

2. 针对常规运行调整阈值，以验证应用程序是否继续提供预期的性能并且不产生任何错误。

3. 为混沌测试使用单独的基线，以容忍预期的错误率峰值和暂时降低的性能。

此活动是连续的，需要定期进行。 例如，引入新功能或更改服务 SKU 后，就需要查看基线。

使用 Azure 负载测试评估阈值

在开发阶段，组件的性能和资源要求通常并不清楚。 负载测试有助于确定整个解决方案及其组件的预期性能，包括横向扩展行为。 它们还有助于确定生成基线所需的阈值。

提出以下问题并定期重新评估：

• 单个操作、用户流或 API 调用需要多长时间才能完成？
• 组件每秒可以处理多少个请求、操作和并发用户？
• 消耗了多少资源？
• 10、50 和 100 位并发用户会如何影响底层基础结构和后端服务？
• 组件何时应横向缩减和扩展？

答案将引导至测试和阈值。 每秒请求数、响应时间和错误百分比都是阈值的适用示例。

记录详细信息后，使用相应的值以一致的方式分析和评估整体解决方案及其组件的性能。 此外，使用基线来确定更改的影响以及与预期性能的偏差。

运行测试时，你可能对特殊用例（例如组件故障或负载峰值）有不同要求。 在这些情况下，预期可能出现较高的错误率或较低的每秒请求数并可接受。 可以有一个单独的基线，其中包含经过调整的阈值，以适应这些情况。 例如：

• 可能出现并需要横向扩展操作的高负载场景。 操作完成之前，性能可能会暂时下降。
• 混沌试验，属于持续验证管道的一部分。 在复原措施开始自我修复应用程序或故障转移到另一个区域之前，预期错误率可能会更高。

使用 Azure 负载测试 评估系统如何根据定义的阈值执行。 该服务具有内置的 测试条件 功能。 也就是说，可以指定负载测试需要通过的条件。

可以使用测试条件来实现不同的基线，如以下示例屏幕截图所示。

可以在 JSON 中指定这些测试条件，并使用 API 将其添加到负载测试。 下面是一个示例：

[
  {
    "passFailMetrics": {
      "<guid-1>": {
        "clientmetric": "requests_per_sec",
        "aggregate": "avg",
        "condition": "<",
        "value": 1200.0,
        "actualValue": 0.0,
        "result": null,
        "action": "continue"
      },
      "<guid-2>": {
        "clientmetric": "response_time_ms",
        "aggregate": "avg",
        "condition": ">",
        "value": 75.0,
        "actualValue": 0.0,
        "action": "continue"
      },
      "<guid-3>": {
        "clientmetric": "error",
        "aggregate": "percentage",
        "condition": ">",
        "value": 0.0,
        "actualValue": 0.0,
        "action": "continue"
      }
    }
  }
]

持续验证的另一个重要方面是注入模拟真实问题的测试。 在下一单元中，你将了解如何将混沌试验添加到验证过程中。