我在亚马逊的AWS服务器上托管Web应用程序。我目前正在使用JMeter加载测试应用程序。我的主要问题似乎是，当我通过弹性负载均衡器（ELB）来访问Amazon服务器而不是直接访问服务器时，我的吞吐量似乎达到了上限。JMeter吞吐量在亚马逊ELB上下降时下降
如果我直接打我的web应用程序 - 对于每个服务器，我能够实现每台服务器50 RPS的吞吐量。
如果我通过亚马逊的ELB打我的web应用程序 - 我只能够达到最大吞吐量50 RPS（总）
我想知道是否有人遇到过类似的行为时，通过亚马逊的利用JMeter负载测试ELB。
有关更多上下文，我的Web应用程序是一个REST应用程序，它允许用户通过HTTP请求下载内容（〜150 kb）。
我正在运行带有以下标志“-Dsun.net.inetaddr.ttl = 0”的Jmeter并使用10个线程运行它。我试过用不同机器上的多个客户端运行这些测试。
感谢您提前提供任何帮助。
负载均衡器测试起来可能比较棘手，因为它们可能有不同的协调流量的机制，具体取决于来源。最常用的方法来区分请求的来源并将其重定向到服务以前请求的同一主机是一个cookie。您可以查看HTTP Cookie Manager以正确操作您的Cookie，并确保每个测试线程或线程组都有不同的测试线程（取决于您的使用案例）。另一个片状区域是起始主机IP。您可能需要将每个测试线程绑定到不同的IP地址，以便在负载均衡器后面碰到不同的服务器。对于亚马逊LB而言，DNS也可能存在一些问题。有用的指南how to test Amazon ELBs
最有可能的原因是jmeter的DNS缓存。 ELB返回额外服务器的IP，具体取决于如何设置自动调节，但JMeter不使用这些额外的服务器。通过确保Jmeter不缓存DNS结果可以解决此问题...
ELB是一个名称，而不是IP，并且可能遭受DNS缓存。请确保您使用“-Dsun.net.inetaddr.ttl = 0”开始时JMeter的
一个真正反应迟缓，而且比原来的问题略有不同，但我希望这可以帮助别人，因为它花了我一段时间才弄完了。由于ELB，我的原始问题并不是吞吐量降低，而是引入了HTTP 503错误。实际上，与直接查询Web应用程序相比，ELB增加了我的吞吐量，但即使经过1小时的测试，结果也是零星的。
首先，ELB具有两级负载均衡功能。第一个负载平衡是跨越ELB的。这是通过将多个IP地址与AWS提供的ELB提供的主机名关联来完成的。当然，第二个是ELB背后的应用程序实例。
没有试图冒犯SO神，这是一个非常有用的文章。
https://blazemeter.com/blog/dns-cache-manager-right-way-test-load-balanced-apps
在那里最有用的信息是使用JMeter的DNS缓存管理器模块。这将查询多个DNS服务器，并删除您的DNS缓存。
我实现了这个模块，然后安装Wireshark，过滤属于ELB主机名的两个IP地址，果然，它查询的是两个IP地址，但明显优于其他IP地址。
这并没有太大的区别，至少不是在短期的测试。
当我调整ELB健康设置时，真正的差异（吞吐量的2-3倍）来了。我最初的错误率很高，但是在减少不健康的门槛和健康检查之间的间隔后，我的错误率大幅下降。
此外，虽然我所有的其他测试持续时间为60-90分钟，但这个测试是8小时。我开始时吞吐量很好，然后迅速下降（约2/3）。大约20分钟或更长时间后，吞吐量开始回落，并且在测试结束时，它的吞吐量是我没有ELB时的吞吐量的5倍（这与吞吐量很快下降时的吞吐量相似在开始这个测试之后）。