Loadrunner代理计划

Question

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

1. 对于一台真实机器的代理商而且该代理商已被划分为某些虚拟机，哪个计划会导致服务器上的负载增加？
2. 如何在性能测试期间监控可能成为瓶颈的代理？
3. 对于每个代理，最低配置（CPU，内存等）是什么？

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

Answer 1

我正在使用LoadRunner代理作为Load Generator代理来回答这个问题。如果这是指监控，那么请考虑通过BAC或Sitescope利用SSH的无代理模型。

最理想的是，使用基础硬件，而不是虚拟机。你需要做得很好;如果你走虚拟机路线，就会意识到所有的初始条件，管理程序经纪和时间记录完整性问题。您还需要在测试结果中披露这些众所周知的问题，因为这些问题会影响测试的完整性和可重复性。

这是我在12之前推荐的64位负载生成器

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

• 通过64位负载生成，Go可以获得最胖的服务器。具有32 GB GB RAM的四核Xeon非常棒。相同的硬盘驱动器配置适用于基于Atom的32位负载生成器模型

就数量而言？服务器数量不是决定性因素，而是每个虚拟用户的资源用户数量和虚拟用户的权重。根据您的虚拟用户类型，其权重和虚拟用户主机的大小，您可以为每个主机提供4-5K用户。在虚拟用户的基础上交换虚拟用户类型和资源指纹上的一些项目，您可以将该限制减少到几十个。

至少你要看三个负载发生器，一个作为控制组，两个作为主负载。了解我如何知道我的负载生成器是否对结果着色，您应该像监控应用程序基础架构一样监控负载生成器。

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

在混合的多应用程序控制模型中，如果您的控制用户组与常规用户组同时降级（意外），那么您的测试中会出现日志生成器引发的延迟。预期的模型将是您的控件集在整个测试执行周期中始终如一地运行。对于控制生成器模型，如果您的控制组和全局组出现性能下降，那么您就会遇到问题的共同来源，即公共网络的应用。如果控制组在非控制组的情况下没有降级（甚至变得更快），那么您的性能时间就会产生负载生成器问题。

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