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