我知道负载生成器的过载会影响执行时间和数量（每小时的事务数），但我不确定它是否也会影响响应时间，我的假设是它不会影响响应时间，如果我错了请让我知道它将如何影响响应时间？
问问题
1343 次
4 回答
2
在比较重载和未重载的负载生成器时，第一个将记录减少的响应时间，因为在发出请求时注入处理延迟会降低命中率。换句话说，过载的负载生成器会错误地报告更高的性能。仅当在这两个测试中，您的应用程序不会出现导致更快完成的事务失败的性能错误时，这才是正确的。
于 2016-04-12T22:06:24.970 回答
2
无论您使用什么工具，它都会影响您的响应时间，例如：
- cpu 过载将使工具进程响应更慢，至少影响完整加载时间
- 网络过载将影响响应时间，因为会发生争用
- 垃圾收集也会影响它......
所以经验法则，永远不要有一个超载的注射器。
于 2016-04-12T13:04:29.633 回答
1
响应时间将受到负载生成器过载的影响。负载生成器负责发送请求、接收响应和处理响应（验证等）。发送、接收和处理都可能受到过饱和的负载生成器的影响，从而导致吞吐量降低，尽管问题主要在于处理。
如果工具在注册已收到响应时出现延迟，这可能会影响报告的响应时间并报告比实际响应时间更慢的响应时间。当请求尝试下载其他资源（CSS、JS、图像）时，情况会变得更糟，因为这会使问题成倍增加。
于 2016-04-12T23:40:23.377 回答
1
你的假设是不正确的。过载的负载生成器会影响响应时间，因为主机上所有内容的执行速度都会变慢，包括虚拟用户。即使为您的虚拟用户调高日志级别也会减慢您的响应时间，因为这会在数十个/数百个将日志写入磁盘的竞争进程中引入磁盘约束和磁盘写入头仲裁 - 这就是为什么建议只使用“ write on error”作为您正在测试的日志级别。不成熟的测试工具用户倾向于编写糟糕的测试代码，这会占用 CPU 和内存资源，这反过来会导致您可以在主机上运行的用户数量减少，而不会影响用户的性能。
有许多经验法则可以帮助您识别与负载生成器影响相关的问题。其中第一个是在测试中使用控制因子。如果您还记得，控制因子是您的测试设计中的一个元素，它允许您测量测试本身的完整性，而与正在测试的内容无关。在性能测试的情况下，您可以引入一个控制应用程序，该应用程序将在您的测试期间与虚拟用户并行运行，也可以引入一个控制负载生成器。
使用控制应用程序，您只需在每个负载生成器上为控制应用程序包括少数用户。这些用户在测试期间运行。它们的响应应该是恒定的，不会由于控制应用程序上的低负载而降低。如果您在对照组中确实观察到响应时间的下降，那么您就会对响应时间产生影响。您有一个过载的负载生成器。
在第二种情况下，控制生成器，您拥有所有硬件匹配的负载生成器，并且您在控制负载生成器上运行每种类型的单个虚拟用户，这是一个负载非常轻的控制生成器。在测试期间，观察控制负载生成器的响应时间与类似类型的其余部分的响应时间。如果控制负载生成器组和全局组（其他负载生成器）以相同的速率降级，那么您会遇到应用程序引发的性能问题，并且您对结果有很高的信心。如果您观察到全局时间正在下降但控制组没有下降，那么您就会遇到负载生成器过载导致本地虚拟用户性能下降的问题。
在任何一种情况下，除了控制器节点之外，建议您至少使用三个负载生成器。使用控制应用程序，您将看到最少三个之间的平衡负载。使用控制负载生成器，您将看到两个用于主负载，一个用于控制负载。请记住，三个是负载生成器的最小数量。根据您的负载和您的技术堆栈，您可能会看到 100 个负载生成器，您需要控制元素作为其中的一部分。
其他经验法则：对于负载生成器（CPU、磁盘、内存、网络）上的任何给定有限资源，切勿超过可用资源池的 75%，否则您的 ring 0 资源命中将降低您的虚拟用户性能，因为核心资源具有由操作系统提供服务。这导致假设您监控负载生成器就像监控被测应用程序一样。
尽量减少日志记录。注意在您的虚拟用户进程上进行交换，因为所有工具制造商都已将其测试工具虚拟用户标记为有资格进行交换。发生这种情况时，您会受到磁盘和内存的影响。独立于您的被测应用程序而减慢用户速度的坏魔法。
于 2016-04-13T15:06:58.773 回答