压力测试计划-JMeter

Question

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

Out团队的目标是确定我们应用程序当前的后端基础架构（AWS API网关，AWS Lambda和AWS MySQL RDS）是否可以支持100,000个每日用户。我对这个问题的思考方式如下：

输入：

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

计划：

1. 最有可能的用户将不会在16小时内均匀分布，因此让我们使用3倍的平均值（100K用户/ 16小时）* 3 = 18,750 用户/小时
2. 尽管我们希望用户在我们的应用上花费30分钟，但我们假设只有10分钟的时间会出现在高峰区域。因此，我们需要模拟 3,125 个并发用户（18,750个用户/小时* 10分钟/ 60分钟）

问题：

1. 上面的逻辑听起来合理吗？
2. 在JMeter中模拟这种负载的正确方法是什么？
3. 我们应该调查线程数（如果可以的话）吗？
4. 我们应该调查吞吐量（如果是的话，我们应该寻找什么值）？
5. 其他吗？

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

谢谢， gen

Answer 1

您的逻辑很好，除了您似乎将VUsers与访问x小时（或 target 吞吐量，也就是容量）相混淆。以下calculator验证您的计算。

IMO，因为您知道目标TP（SLA），所以实现工作量的一种简单方法是使用Arrivals Thread Group提交工作量（请求）。该TG将实例化维持目标TP所需的线程数。

Answer 2

您描述的内容看起来像Load Testing，Stress Testing有所不同，它不是要检查应用程序是否可以支持10万用户，而是要查找第一个bottleneck

通常该过程如下：

1. 您以1个线程（虚拟用户）开始

2. 您逐渐增加负载，直到：

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

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

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

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

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