Performance Loadrunner代理计划

我必须计划代理（容量和数量等），因为我们的网站将在一个月内增长到200多台服务器。我的问题如下:

对于一个代理，它是一个真正的机器，而这个代理被划分为一些虚拟机，哪个计划会导致服务器上的负载增加

如何监控可能成为性能测试瓶颈的代理

对于每个代理，最小配置是什么（CPU、内存等）

---

所有代理都是Linux操作系统。提前感谢。

我使用LoadRunner代理作为Load Generator代理来回答这个问题。如果这是指监控，那么考虑无代理的模型，利用SSH通过BAC或Sitescope。 最好使用基本硬件，而不是虚拟机。你需要非常好；了解所有初始条件、虚拟机监控程序代理和计时记录完整性问题（如果您选择虚拟机路径）。您还需要在测试结果中披露这些众所周知的问题，因为这些问题会影响测试的完整性和可重复性

下面是我推荐的12之前的版本，它引入了64位的load Generator

• Atom双核4GB、引导驱动器SSD、应用程序和交换驱动器SATA3 10K或更高。如果要从虚拟用户捕获日志，则需要第二个驱动器阵列通过光纤通道与另一端的raid阵列连接。在任何情况下，日志都会延迟

• 使用64位负载生成，选择您能得到的最胖的服务器。具有32-GB内存的四核Xeon将非常棒。这里的硬盘配置与基于Atom的32位load generator型号相同

至于数字？服务器的数量不是决定因素，而是用户的数量和虚拟用户在每个虚拟用户资源方面的权重。根据您的虚拟用户类型、其重量和虚拟用户主机的大小，每个主机可能有4-5K个用户。交换虚拟用户类型上的一些项目和虚拟用户基础上的资源指纹，您可能会将该限制降至几十个

您至少要查看三个负载生成器，一个作为控制组，两个作为主负载。说到我如何知道我的load Generator是否对结果着色的问题，您应该像监视应用程序基础结构一样监视load Generator

控制生成器将在这方面发挥重要作用。回到测试概念，每个测试都应该包括一个控制因素。对于性能测试，您可以在固定负载下的每个load generator上包含一组参考应用程序的虚拟用户，并观察这些用户是否降级，或者您可以包含一个单独的控制生成器、与其余load generator匹配的硬件，但包括每种类型的单个虚拟用户

在混合的多应用程序控制模型中，如果您的控制组用户与您的常规用户同时（意外地）降级，那么您的测试将出现日志生成器导致的延迟。期望的模型是您的控件集在整个测试执行周期中一致运行。对于control generator模型，如果您的控制组和全局组出现降级，则您有一个共同的问题来源，即公共网络的应用程序。如果控制组没有降级（或者甚至更快一点），而非控制组降级，那么您的性能时间就会出现由load generator引起的问题

---

您的控制生成器应始终在硬件上。为什么，由于虚拟机上的时钟浮动问题、不同的初始和测试条件，您需要一个参考样本来测量负载生成器模型在虚拟机上施加的偏差

，感谢您提供的详细提示。顺便说一句，你能解释一下吗：？没有足够的细节来回答另一个问题。