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