Loadrunner TruClient和足够的吞吐量/httsPerSecond

Question

我对单个url (OpenAM isAlive.jsp站点)运行LoadRunner http协议请求，使用100 VUsrs (http)获得每秒大约1000/900次命中。

使用TruClient运行类似的测试，我尝试运行100 VUseres，当我达到大约40个卡车客户端VUsers时，吞吐量实际上会下降，一些请求失败，吞吐量下降到大约0 (!)

对于失败的事务和/或错过的请求，TruClient是否合理？好像有些人不及格就会毁了整个测试？

我想为我的SUT生成足够的负载。

有什么想法吗？

它既不是负载生成器，也不是被测系统(SUT)。

任何评论都将不胜感激！

BR Magnus Fuglerud

Answer 1

您的问题出在负载生成器中。Truclient协议实际上会在负载生成器机器上打开一个真正的浏览器。当在同一台机器上打开40个用户时，您会导致RAM和CPU问题，这会导致浏览器运行缓慢并卡住。

你应该准备一个庞大的负载测试机器阵列，要运行40个用户，我认为你至少需要4台计算机。

在尝试生成大量负载时，它不是最有效的协议。如果可能，我会使用AJAX或HTTP。

科比。

Answer 2

我的假设是你有一个单一的饱和负载生成器，当你从40个用户减少到100个用户时，它几乎是零。这种虚拟用户类型的重要性就是为什么我回避它的一般使用，而将它归类到少数或更少的地方，因为有某种“渲染”需求的人不了解性能测试的重点。

看看你的测试床。至少你应该在你的测试床上有三个负载生成器，硬件匹配。两个用于主负荷，一个用于控制装置。这是独立于控制器的。在两个“主要负载”生成器上运行大部分负载，并在控制生成器上运行每个业务功能类型的一个虚拟用户。在测试期间注意您的事务响应时间

如果您看到控制组的事务响应时间与全局组的事务响应时间开始不同，那么就有问题了。当控制组继续以相同的速度或更快的速度继续时，全局平均变长是负载发生器受损的绝对迹象，与工具无关，也与用于测试的协议无关。

还要考虑迁移到一个模型，其中您的大部分负载是http，只有少数是Truclient，在那里运行它们是为了满足任何其他方式都无法满足的需求。可能有一些技术环境需要更高层的开发方法，但这些方法很少，特别是当您删除对第三方服务的调用时，这些调用无论如何都不会包括在性能测试中。