压力测试计划 - JMeter

Question

我是压力测试的新手，并希望确保我以正确的方式接近它。

Out 团队的目标是确定我们的应用程序当前的后端基础设施（AWS API Gateway、AWS Lambda 和 AWS MySQL RDS）是否能够支持 100,000 名每日用户。我对这个问题的思考方式如下：

输入：

• 10 万用户/天
• 16 小时/天 - 因为我们拥有全球用户群
• 用户在应用上平均花费 30 分钟

规划：

1. 用户很可能不会在 16 小时内均匀分布，因此我们使用 3 倍平均值，即（100K 用户/16 小时）* 3 = 18,750 用户/小时
2. 虽然我们预计用户会在我们的应用程序上花费 30 分钟，但我们假设其中只有 10 分钟会在高峰区结束。因此我们需要模拟3,125个并发用户（18,750users/hour * 10min / 60min）

问题：

1. 以上逻辑合理吗？
2. 在 JMeter 中模拟此类负载的正确方法是什么？
3. 我们是否应该查看线程数（如果是，有多少）？
4. 我们是否应该调查吞吐量（如果是，我们应该寻找什么值）？
5. 还有吗？

任何建议都将受到高度赞赏。

谢谢， 基因

Answer 1

你描述的看起来像Load Testing，Stress Testing 是不同的，不是检查应用程序是否可以支持 10 万用户，而是更多关于找到第一个 bottleneck

通常流程如下：

1. 你从 1 个线程开始（虚拟用户）

2. 你逐渐增加负载直到：

   • 您的应用程序应该支持的最大用户数已达到
   • 您检测到性能下降（响应时间增加、吞吐量降低、开始出现错误，无论先发生什么）

在理想系统上，当您将负载增加给定因子时，吞吐量（每秒请求数）应该会增加完全相同的因子，并且响应时间应该保持不变（或下降）。

如果响应时间增加，则意味着系统无法处理负载，您需要确定原因（最慢的组件）并检查是否可以以某种方式对其进行优化。

对于“负载测试”，您的假设看起来有效

更多信息：Why ‘Normal’ Load Testing Isn’t Enough

Answer 2

您的逻辑很好，只是您似乎将 VUser 与 x 小时访问次数（或 目标 吞吐量，又名 容量）混淆了。以下calculator 验证您的计算。

IMO，既然您知道目标 TP (SLA)，实现工作负载的一种简单方法是使用 Arrivals Thread Group 提交它（请求）。此 TG 将实例化维持目标 TP 所需的线程数。