我正在亚马逊的AWS服务器上托管一个Web应用程序。我目前正在使用JMeter对应用程序进行负载测试。我的主要问题似乎是，当我通过Elastic Load Balancer（ELB）来攻击亚马逊服务器而不是直接点击服务器时 - 我似乎达到了我的吞吐量上限。
如果我直接点击我的Web应用程序 - 对于每台服务器，我能够为每台服务器实现50 RPS的吞吐量。
如果我通过亚马逊的ELB点击我的网络应用程序 - 我只能达到50 RPS（总计）的最大吞吐量
我想知道是否有其他人在使用Jmeter通过亚马逊的ELB进行负载测试时遇到过类似的行为。
对于更多上下文，我的Web应用程序是一个REST应用程序，允许用户通过HTTP请求下载内容（~150 kb）。
我正在使用以下标志“-Dsun.net.inetaddr.ttl = 0”运行Jmeter并使用10个线程运行它。我尝试在不同的机器上运行多个客户端的这些测试。
感谢您提前提供任何帮助。
答案 0 :(得分：0)
负载平衡器可能很难测试，因为它们可能具有根据原点协调流量的不同机制。最常用的方法是区分请求的来源并将其重定向到服务于先前请求的同一主机，这是一个cookie。您可以查看HTTP Cookie Manager以正确操作您的cookie，并确保每个测试线程或线程组都有不同的（根据您的用例）。另一个片状区域是源主机IP。您可能需要将每个测试线程绑定到不同的IP地址，以便命中负载均衡器后面的不同服务器。关于Amazon LBs，DNS也存在一些问题。关于how to test Amazon ELBs
的有用指南答案 1 :(得分：0)
最可能的原因是jmeter的DNS缓存。 ELB返回其他服务器的IP，具体取决于自动调节的设置方式，但JMeter不使用这些额外的服务器。这个问题可以通过确保Jmeter不缓存DNS结果来解决......
ELB是一个名称，而不是IP，并且可能遭受DNS缓存。启动JMeter时确保使用“-Dsun.net.inetaddr.ttl = 0”
答案 2 :(得分：0)
一个非常晚的回应，与原来的问题略有不同，但我希望这可以帮助别人，因为我花了一段时间才能完全理解。我最初的问题不是由于ELB导致吞吐量降低，而是引入了HTTP 503错误。实际上，与直接查询Web应用程序相比，ELB增加了我的吞吐量，但即使进行了1小时的测试，结果也是零星的，至少可以说。
首先，ELB正在进行2阶段负载平衡。第一个负载平衡是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倍（这与短时间内的吞吐量相似）在开始这个测试之后）。