我针对单个网址（OpenAM isAlive.jsp网站）运行LoadRunner http协议请求，并且使用100 VUsrs（http）获得大约每秒1000/900次点击吞吐量。
使用TruClient运行类似测试我尝试运行100 VUseres，当我达到大约40个truclient VUsers时，吞吐量实际上降低了，一些请求失败了，吞吐量降低到大约0（！）
TruClient对交易失败和/或错过请求是否合理？好像有些失败会破坏整个测试？
我想为我的SUT产生足够的负载。
有什么想法？
它不是负载发生器，也不是被测系统（SUT）。
任何会员都将不胜感激！
BR Magnus Fuglerud
答案 0 :(得分：3)
您的问题出在负载生成器中。 Truclient协议实际上在负载生成器机器上打开REAL浏览器。 在同一台计算机上打开40个用户时，会导致RAM和CPU出现问题，导致浏览器执行缓慢而卡住。
你应该准备一个大型的负载测试机器阵列，运行40个用户，我会说你需要至少4台电脑。
在尝试生成大量负载时，它不是最有效的协议。如果可能的话，我会使用AJAX或HTTP。
Koby。
答案 1 :(得分：1)
我的假设是你有一个饱和负载发生器，当你从truclient下的40个用户变为100个时，它正在减慢到几乎为零。这种虚拟用户类型的重量是我回避它的一般用途，并将其降级为少数或更少的原因，而那些不了解性能测试重点的人会有某种“渲染”需求。
看看你的试验台。最低限度，您的测试台中至少应有三个负载发生器，硬件匹配。两个用于主要负载，一个用于控制组。这与控制器无关。在控制生成器上的两个“主要负载”生成器和每个业务功能类型的一个虚拟用户上运行大部分负载。在测试期间观察您的交易响应时间
如果您发现控制组的事务响应时间开始与全局组不同，则表示您遇到问题。当控制组继续以相同的速度或变得更快时，全局平均延长是负载生成器遇险的绝对标志，与工具无关且独立于用于测试的协议。
另外考虑转移到一个模型，其中大部分负载是http，只有少数是Truclient，运行它们以满足任何其他方式都无法满足的要求。可能存在需要更高层开发方法的技术环境，但这些方法很少，尤其是当您删除对性能测试中未包含的第三方服务的调用时。