本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 负载测试类型
<a name="test-types"></a>

以下测试类型基于本指南前面列出的基本问题。

## 我的应用程序能承受多少负载？
<a name="load-size"></a>

在设置测试以确定应用程序可承受的负载时，首先要确定是以每秒请求数（req/s）、响应时间（秒）还是以并发用户数来衡量。无论哪种情况，都要定义测试应用程序的哪一部分。
+ 浏览站点是一种负载，通过访问多个页面或端点，或者通过为每个请求使用不同的参数从单个端点请求数据来实现。您通常可以通过使用*[可用工具](tools.md)*部分中描述的基本工具来实现这一点。由于缓存通常是应用程序的重要组成部分，因此请决定是否要在测试中包含缓存层。
+ 测试事务性工作流程需要更复杂的工具，比如请求相互依赖，在请求之间传送数据的签出。此外，由于请求度量在多步骤事务的上下文中的相关性有限，因此对整个事务进行计数更为准确，该工具必须将其作为单独的数据点发出。可以将 Apache JMeter 和 k6 工具配置为提供这些数据点。

为目标系统的性能和错误率定义可接受的阈值。对于某些系统，您可能不关心响应时间，只要成功处理事件即可。对于许多应用程序（比如具有用户交互功能的应用程序），定义最终用户可接受的限制。

分步执行测试通常很有帮助。负载随着每一步的进行而增加，直到达到定义的阈值。对于重复测试，您可以从之前的测试中吸取教训并改进步骤，以减少测试中执行的步骤，同时仍能获得有效的结果。

## 我的应用程序能否处理 X 负载？
<a name="x-load"></a>

与之前的测试类似，此测试中的负载可以定义为 req/s 或定义为并发用户，具体取决于所测试的应用程序的性质。该测试是上一个测试的简化版本。这里，必须提交特定的工作负载，并且系统应该能够处理它。选择一款支持指定所需负载量的测试工具非常重要。

运行测试的时间也可能相关。只有当测试运行时间较长时，才能观察到某些影响。例如，反向压力可能会导致队列过载。如果要复制生产系统并得出有效的结论，运行测试所需的时间可能会影响测试系统的规模。

## 我的应用程序会不会自动扩缩？
<a name="scaling"></a>

弹性是云的关键卖点，也是降低成本的关键来源。测试您的应用程序是否正常扩展，以便您可以放心地从弹性中受益，这应该是您的云之旅的一部分。

需要确定用于规模扩缩的关键指标。通常，这是目标系统的 CPU 负载。可将产生 CPU 负载的端点作为目标。

因为该测试不要求可表示性，所以您可以从定位无副作用的端点中获益。您也不希望启动一个流程来保存可能累积的数据，或者启动后续流程并产生不必要的成本或阻止负载。

分步执行测试，逐渐增加负载。间隔应足够长，以便在每个步骤中，指标都能够启动扩展。例如，如果您的规则是 CPU 负载在 5 分钟内高于 70%，那么您的步骤应该长于 5 分钟，以便为启动和运行扩展事件留出时间。您还希望看到扩展正常工作，并修复了您创建的负载情况。

考虑在多台服务器上开始扩展测试。在小型环境中，扩展速度可能很慢，需要多个周期来处理负载。EC2 Auto Scaling 集群的大小只能增加一倍。这意味着，如果从一台服务器开始并启动负载测试，则最大的首次扩展事件只能是两台服务器。如果生成的负载需要三台服务器，则需要两个扩展事件，这可能需要 20 分钟或更长时间。

监视扩展事件所需的触发器以及扩展是否适合实际负载。

如果您已实现缩减事件，也可以逐步进行测试。监控缩减是否适用于现有负载，并确认不会立即再次启动扩展。

## 在持续高负载的情况下，我的应用程序行为是否会随着时间的推移而下降？
<a name="constant"></a>

只有当长时间产生负载时，才能观察到某些影响。最重要的影响之一是反向压力。这意味着，当系统速度太慢而无法以请求的速度处理请求数量时，其客户端系统的性能就会下降。

如果慢速系统是负载目标，则更容易观察到这一点。在更复杂的设置中，只有当负载测试的影响传播时，才能观察到效果。能够可视化分布式系统中每个服务之间的响应时间的跟踪解决方案不仅可以更快地显示结果，还可以帮助识别充当瓶颈的系统。您可以通过从日志文件中获取消息相关性 ID 来识别瓶颈系统。在所有经过负载测试的系统中，每个请求都保留相同的 ID。

使用相关性 ID 可以帮助您跟踪单个消息在平台所有不同组件中的整个旅程。有了这些信息，您就可以计算消息遍历每个组件的处理时间（processing\_time = departure\_time – arrival\_time），并确定速度最慢的组件。[Zipkin](https://zipkin.io/)、[Jaeger](https://www.jaegertracing.io/) 和 [AWS X-Ray](https://aws.amazon.com/xray/) 是该领域的突出解决方案。

为了获得最可靠的结果，请选择支持设置恒定请求速率的工具。这意味着，如果目标系统变慢，则测试工具的并发度必须增加或保持 req/s 不变。当系统响应开始变慢时，就会占用更多的线程，降低负载生成工具的请求速率。具有恒定请求速率的工具在发生并发时必须增加并发度，您将更快地看到失败。您将通过延迟甚至失败的请求来衡量，而不是通过实现的 req/s 来衡量性能下降。

## 我的应用程序是否正常工作？
<a name="working"></a>

通常，您不会创建高负载，而是创建合理数量的请求来验证功能。您还可以在客户不访问测试流程时定期针对生产环境执行此操作，以进行另一层监控。

一条捷径是，已针对负载测试创建的场景可以在配置了低负载的生产环境中重用。