0

使用这些指标（如下所示），我能够利用工作负载建模公式（小定律）提出我认为正确的设置来充分负载测试相关应用程序。

来自谷歌分析：

  • 用户：2,159
  • 浏览量：4,856
  • 平均 会话持续时间：0:02:44
  • 页数/会话：2.21
  • 会话：2,199

公式为 N = 吞吐量 *（响应时间 + 思考时间）

  • 我们将吞吐量计算为 1.35（4865 次网页浏览量 / 3600 次（一小时秒数））
  • 我们计算（响应时间 + 思考时间）为 74.21（平均 164 秒会话持续时间/每个会话 2.21 页）

使用该公式，我们将 N 计算为 100（1.35 吞吐量 * 74.21（响应时间 + 思考时间））。

因此，根据我的计算，我们可以模拟服务器在高峰时段的高峰日所经历的负载，其中 100 个用户在迭代之间以 75 秒的速度通过业务流程（认为时间忽略）。

因此，为了确定系统在比正常负载更重的情况下如何响应，我们可以将 N 的值加倍（200 个用户）或三倍（300 个用户），并记录每个事务的平均响应时间。

这一切都正确吗？

4

2 回答 2

0

下面的公式对我来说总是很好，如果你想计算节奏，
"Pacing = No. of Users * Duration of Test (in seconds) / Transactions you want to achieve in said Test Duration"
你应该能够更接近你想要使用这个公式实现的交易。如果它的 API，那么它几乎总是准确的。

例如，您希望在一小时的测试持续时间内使用 5 个用户实现 1000 个事务

起搏 = 5 * 3600/1000 = 18 秒

于 2020-08-22T14:08:31.267 回答
0

当您直接观察站点的日志时，按会话持续时间阻止，每个块中计算的最大 IP 地址数是多少？

Littles 定律倾向于低估会话及其开销，以支持事务吞吐量。如果您对会话资源有即时恢复，那没关系，但大多数站点保留它们的时间超过用户最长请求间窗口的 110%（从一个请求到下一个请求的时间段）。

于 2020-08-22T14:49:08.423 回答