负载测试的基础规划 - AWS 规范性指导

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

负载测试的基础规划

要确定负载测试的正确工具和设置,首先要明确运行测试的原因。以下问题必须通过正确的测试类型来解决:

  • 我的应用程序能承受多少负载?

  • 我的应用程序能否处理 X 负载?

  • 我的应用程序会不会自动扩缩?

  • 我的应用程序行为是否会随着 X 负载量的增加而下降?

  • 我的应用程序是否正常工作? (这不是典型的负载测试,但您可以使用负载测试工具来确定您的应用程序是否按预期运行。)

确定测试复杂性

测试的复杂性取决于评估的完成程度。Heyab 等基本工具可以针对单个应用程序 URI 运行请求。这些工具是最有效的,但它们仅测试应用程序的一个方面。在某些情况下,已经足够。例如,如果想要测试扩展,只需对端点进行调用,在要测试的维度中施加负载。例如,CPU 负载可以是巨大的有效负载,也可以是产生 CPU 负载的密集计算。如果您使用的是分布式系统,则可能需要调用一个端点来启动复杂的分布式进程。

在其他情况下,可能需要通过测试来执行复杂的行为。例如,您需要在启动流程之前登录,或者您正在测试包括选择项目和执行购买的订单流程。这可以理解为一种场景。测试场景需要更复杂的负载测试工具,在这些工具中,您可以根据实际情况来调整工作负载。这将生成结果,您可以使用这些结果来断言最终用户将体验到的性能。

复杂的测试会在负载生成系统上产生更多负载。对于运行负载测试,不仅要考虑工具,还要考虑运行该工具的系统,其 CPU 和网络带宽是最重要的方面。设计不当的负载测试计算机系统可能会导致错误的结果。例如,一台计算机不足以为性能良好的目标创建负载。在这种情况下,必须设置分布式负载测试。另一方面,性能良好的工具会在单个服务器上产生更多的负载。这将在测试设置的讨论中深入阐述。

测量和设置

必须考虑测试环境的可表示性。如果您在运营一个拥有数千台服务器的大型购物网站,那么在不影响最终用户的情况下测试生产,或者创建与网站规模相当的测试环境可能会很困难。此外,要产生足够的流量,以对这种规模的系统施加压力,还需要复杂的负载测试设置。因此,负载测试通常在较小、类似的设置上运行,您可以使用这些设置对生产环境做出假设。建立基线或功能要求的测试可以在生产环境中运行。

最好为后续测试记录测试环境,这样您就有了一个定义明确的规范,可以根据目标环境的大小期望得到什么样的结果。

考虑基础设施中受负载测试影响的所有元素。虽然测试通常着眼于主机的 CPU 和内存,但还需要考虑其他相关的副作用。

一个典型的副作用是,服务之间通信的网络带宽可能会达到极限。对于通过互联网连接的服务或分布式系统,通信通常基于网络。使用对应用程序施加压力的负载测试也会给底层网络基础设施产生压力。

负载建模和分步测试

对于不同的测试,您可以对测试过程中产生的负载进行建模。一种基本的方法是创建分步进程,随着时间的推移逐渐增加负载。这将为每个步骤创建不同的数据点,使您能够在一次测试运行中得出详细的结论。要找到与您的应用程序相关的极限,最好在低于预期最佳性能的典型使用情况的负载下开始测试。当您逐渐增加负载时,您将看到应用程序性能下降的极限。结果将显示预期行为是否仍然有效,以及应用程序在错误情况下行为是否符合预期。例如,当测试超过极限时,您可能期望应用程序降低负载

使用复杂的工具,您可以将模式设置为测试的配置。这将定义一段时间内将产生多少负载,以及它将如何增加或减少。

大多数基本工具都是命令行工具,需要您自己编写解决方案脚本。在编写自己的脚本时,确保不会意外覆盖要保留的指标。每次迭代的输出文件都应添加新的后缀,这样就不会覆盖上一次迭代的结果。