JMeter性能测试—利特尔定律在工作负载模型中的应用

• 2019 年 11 月 21 日
• 笔记

利特尔定律（Little’s law）应该是最著名的排队理论之一！让我们看看如何将其用于性能测试。

利特尔定律(Little’s law)

稳定系统中的长期平均客户数(N)，等于长期平均有效抵达率(λ) 乘以客户在系统中平均花费的时间(W)；可以用代数表达式表示为：N =λW。

利特尔定律是普遍适用的，它可以应用于存在队列的任何地方，从零售商店到CPU /应用服务器。 假设售票柜台中用户平均花费15分钟（W），客户以每小时20个客户的速度抵达（λ），假设每个人都买票。

使用利特尔定律，我们可以随时计算系统中的平均客户数为N =λW λ = 20 /Hour W = 15 min= 0.25 Hour 因此，N为5 =(0.25 * 20)

虽然我们可以预期每小时有20个客户，但由于客户在柜台上仅花费15分钟，所以系统中只有5个客户；队列中有4个，正在维护1个。

抵达率：

客户进入系统的速率称为抵达率。

退出率：

客户离开系统的速率称为退出率。

利特尔定律假设系统稳定，因此到达率和离开率相同。

性能测试中的利特尔定律：

利特尔定律也可以应用于我们的Web /APP/数据库服务器，以关联用户/请求总数，服务器的吞吐量(TP)和平均响应时间。

吞吐量 ––是每单位时间处理的请求数；可以用作退出率（λ）。

响应时间 ––平均响应时间是请求在系统（W）中花费的时间。它包括等待时间+服务时间。

N = 吞吐量 * 响应时间 (N = Throughput * Response Time)

思考时间会影响系统吞吐量。因此，如果有任何思考时间：

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

性能测试结果验证：

让我们看几个例子，以理解为何利特尔定律可以用来验证我们的性能测试执行结果。

• 在我们的tomcat服务器中，在server.xml中更新线程池中的最大线程数只能处理10个并发，如果超过10，它将排队等待。让我们看看在这里如何应用利特尔定律。
• 我还想控制响应时间，更新tomcat示例中的hello.jsp文件，添加了一个显示等待2000毫秒–tomcat需要2秒来处理此请求并做出响应。

现在我们知道访问该页面的每个请求将需要2秒钟的时间来处理，我们也知道池中只有10个线程。 因此，tomcat可以在2秒内处理10个请求，我们将tomcat的服务器吞吐量限制为(10/2 =) 5个请求/秒。

• 我创建了一个包含10个并发用户的简单测试来访问该页面，进行了一段时间的测试。

根据上述JMeter的汇总结果： 平均响应时间（W）为2009毫秒 吞吐量（λ）为5 /秒 因此，系统中的用户数N N = 吞吐量 * 响应时间 N = 5 * 2.009 N = 10.045，非常接近10

• 这次，我对50个 并发用户进行了相同的测试，得到以下结果：

W = 9.742秒 λ = 5 /秒 N = 9.742 * 5 = 48.71 ，接近50 这证实了响应时间与用户负载是同步的。如上所示，可以使用利特尔定律来验证你的性能测试结果是否准确。

工作负载模式：

工作负载模式是由给定并发用户在给定时间内执行的一组业务事务，用于分析被测试系统的行为。 工作负载模式在性能测试中非常重要，如果它不能反映最终用户的模式，那么你的性能测试结果就是浪费!

我们不能创建一个简单的性能测试计划，该计划随机地考虑用户的数量，并具有任意思考时间！ 为了找到合适的工作负载模式，您至少需要提供以下信息：

• 关键业务交易
• VUsers的数量
• 操作用户的百分比
• 思考时间
• 期望吞吐量

通常，上述信息应该由客户/业务分析师等提供；但有时作为一个性能测试工程师，可能会遇到一个问题：即客户对非功能性需求一无所知。然而他们希望进行性能测试；让我们看看如何在Google-analytics工具的帮助下利用利特尔定律来得出一个工作负载模式。 谷歌分析工具可以为我们提供经常访问的页面，对于处理涉及这些页面和某个操作的用户百分比的业务工作流来说，这是一个很好的信息。

吞吐量计算：

对于其中一个应用程序，google-analytics显示的是一年中某一天的峰值信息。

• 20071个用户登录
• 277576次页面浏览 从页面视图中，我们可以计算服务器的吞吐量。 也就是说，如果服务器每天处理277576页，那么它每秒将处理3.2个页面请求。（277576 /（24 * 60 * 60））

但这是不对的！ Google Analytics还提供当天的网页浏览量分布，在高峰时段，我们的服务器在一小时内处理了34435个页面。

因此，我们可以将此峰值小时数用于期望的吞吐量计算。34435 /（60 * 60）给出9.56页/秒，这应该是期望的吞吐量。

思考时间计算：

从上图中可以看出，一个用户会话持续了9分15秒，即555秒。

在会话期间，用户浏览8.78个页面。

两次页面查看之间的时间间隔为555 / 8.78 = 63秒

响应时间+思考时间= 63秒

如果我们知道响应时间，我们就可以相应地调整思考时间。

用户总数计算：

Google Analytics还显示，在高峰时段，我们有大约3904位用户。

事实上，这并不意味着你需要使用3904个并发用户运行负载测试。因为它是一个小时的汇总信息。

根据利特尔定律，用户总数N =吞吐量*（响应时间+思考时间）

    N = 9.56 * 63      N = 602位用户  

602个并发用户足以运行负载测试。

也就是说，通过设计一个持续9分钟15秒、602个用户的测试计划，您将拥有3910个用户登录，这与我们当前的生产工作负载非常接近。

总结：

一些性能测试人员可能知道如何使用JMeter / LoadRunner 或者其他工具制定测试计划，并且是他们认为无论得到什么结果都是准确的。然而事与愿违！ 例如：您的系统资源可能非常有限–如果您对1000个并发用户运行JMeter测试，JMeter会给出一些结果；永远不要假设结果是正确的，要不断的使用利特尔定律交叉核对你的结果，根据JMeter的结果，假设说吞吐量为50 /秒和平均响应时间（包括思考时间）为13秒。

    N = 50 * 13        N = 650        我们的预期N应该是1000左右。所以这里出了问题！！  

因此，可以使用利特尔定律来确保观察到的性能结果是不是由于我们的负载生成工具造成的瓶颈。

若有错误请指出，欢迎留言交流