我必须计划代理（容量和数量等），因为我们的网站将在一个月内增长到 200 多台服务器。我的问题如下：
ps。所有代理都是 Linux 操作系统。提前致谢。
【问题讨论】：
标签： performance performance-testing loadrunner
我使用 LoadRunner 代理作为负载生成器代理来回答这个问题。如果这是指监控，请考虑通过 BAC 或 Sitescope 使用 SSH 的无代理模型。
最好使用基础硬件，而不是虚拟机。你需要很好；如果您采用虚拟机路线，请了解所有初始条件、管理程序代理和时间记录完整性问题。您还需要在测试结果中披露这些众所周知的问题，因为这些问题会影响测试的完整性和可重复性。
这是我在 12 之前推荐的，它引入了 64 位负载生成器
Atom 双核 4GB，引导驱动器 SSD，应用程序和交换驱动器 SATA3 10K 或更高。如果您要从虚拟用户那里捕获日志，那么您需要将第二个驱动器阵列与另一端的 RAID 阵列连接到光纤通道。在任何情况下，您都会遇到日志延迟
使用 64 位负载生成，选择你能得到的最胖的服务器。具有 32 GB RAM 的四核 Xeon 会很棒。此处适用的硬盘配置与基于 Atom 的 32 位负载生成器模型相同
至于数字？服务器数量不是决定因素，而是用户数量和虚拟用户在每个虚拟用户的资源方面的权重。根据您的虚拟用户类型、他们的权重和虚拟用户主机的大小，每台主机可能有 4-5K 用户。在虚拟用户的基础上交换一些虚拟用户类型和资源指纹的项目，您可以将限制降低到几十个。
您至少要查看三个负载生成器，一个作为控制组，两个作为主要负载。解决您的问题，即我如何知道我的负载生成器是否正在为结果着色，那么您应该像监控应用程序基础架构一样监控负载生成器。
控制生成器将在这方面有很大帮助。回到测试概念，每个测试都应该包含一个控制因素。对于性能测试，您可以在每个负载生成器上以固定负载为参考应用程序包含一组虚拟用户，并观察这些用户是否降级，或者您可以包含一个单独的控制生成器，硬件与其余负载生成器匹配，但包括每种类型的单个虚拟用户。
在混合的多应用控制模型中，如果您的控制组用户与您的常规用户组同时（意外）降级，那么您将在测试中遇到日志生成器导致的延迟。预期的模型将是您的控制集在整个测试执行周期中始终如一地运行。对于控制生成器模型，如果您的控制组和全局组出现退化，那么您就有了问题的共同来源，即共同网络的应用。如果控制组没有降级（甚至变得更快），而非控制组却降级了，那么您的性能时间就会受到负载生成器的影响。
您的控制生成器应始终在硬件上。为什么，由于虚拟机上的时钟浮动问题、不同的初始条件和测试条件，您需要一个参考样本来测量负载生成器模型对虚拟机施加的偏差
【讨论】：