EC2 ELB性能问题
关于EC2 ELB的两个问题：
首先是如何正确运行JMeter测试。我找到了以下 http://osdir .com/ml/jmeter-user.jakarta.apache.org/2010-04/msg00203.html，基本上说要设置-Dsun.net.inetaddr.ttl=0 启动 JMeter 时（这很简单），它提出的第二点是路由是每个 ip 而不是每个请求。因此，除了启动一个 jmeter 实例场之外，我不知道如何解决这个问题。欢迎任何想法，或者可能我误读了解释（？）
另外，我有一个 Web 服务正在服务器端调用 java 中的另一个 Web 服务（两者都在 ELB 后面），所以我使用HttpClient 及其 MultiThreadedHttpConnectionManager，我在其中提供了一些到连接管理器中的主机值的大型路由。我想知道这是否会破坏 ELB 的负载平衡行为，因为连接被缓存（而且请求全部来自同一台机器）。我可以每次都切换到使用新的 HttpClient（有点蹩脚），但这并不能解决所有请求都源自少数主机的事实。
背景故事：我正在 EC2 上使用 ELB 对服务进行性能测试，流量分布不均匀（大部分流量流向 1-2 个节点，几乎没有流量流向 1 个节点，根本没有流量流向第 4 个节点）。因此，上述问题是我发现的可能的罪魁祸首。
Two questions about EC2 ELB:
First is how to properly run JMeter tests. I've found the following http://osdir.com/ml/jmeter-user.jakarta.apache.org/2010-04/msg00203.html, which basically says to set -Dsun.net.inetaddr.ttl=0 when starting JMeter (which is easy) and the second point it makes is that the routing is per ip not per request. So aside from starting a farm of jmeter instances I don't see how to get around that. Any ideas are welcome, or possibly I'm mis-reading the explanation(?)
Also, I have a web service that is making a server side call to another web service in java (and both behind ELB), so I'm using HttpClient and it's MultiThreadedHttpConnectionManager, where I provide some large-ish routes to host value in the connection manager. And I'm wondering if that will break the load balancing behavior ELB because the connections are cached (and also, that the requests all originate from the same machine). I can switch to use a new HttpClient each time (kind of lame) but that doesn't get around the fact that all requests are originating from a small number of hosts.
Backstory: I'm in the process of perf testing a service using ELB on EC2 and the traffic is not distributing evenly (most traffic to 1-2 nodes, almost no traffic to 1 node, no traffic at all to a 4th node). And so the issues above are the possible culprits I've identified.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我遇到过非常相似的问题。一件事是 ELB 在突发负载下无法很好地扩展。因此，当您尝试测试它时，它不会立即扩大规模。需要很多时间才能提升。另一个缺点是它使用 CNAME 作为 DNS 查找。仅此一点就会减慢您的速度。您可以研究更多性能问题。
我的建议是使用 haproxy。您拥有更多的控制权，并且您会喜欢这种表演。我对此感到非常高兴。我使用 heartbeat 设置冗余服务器，一切顺利。
另外，如果您计划使用 ELB 进行 SSL，您将遭受更多损失，因为我发现性能低于标准。
我希望这对一些人有帮助。归根结底，AWS 亲自告诉我，负载测试 ELB 并没有真正起作用，如果您计划以大量负载启动，您需要告诉他们，以便他们可以提前扩展您的规模。
I have had very simular problems. One thing is the ELB does not scale well under burst load. So when you are trying to test it, it is not scaling up immediately. It takes a lot of time for it to move up. Another thing that is a drawback is the fact that it uses a CNAME as the DNS look up. This alone is going to slow you down. There are more performance issues you can research.
My recommendation is to use haproxy. You have much more control, and you will like the performance. I have been very happy with it. I use heartbeat to setup a redundant server and I am good to go.
Also if you plan on doing SSL with the ELB, you will suffer more because I found the performance to be below par.
I hope that helps some. When it comes down to it, AWS has told me personally that load testing the ELB does not really work, and if you are planning on launching with a large amount of load, you need to tell them so they can scale you up ahead of time.
您没有说明您正在运行多少个 jmeter 实例，但根据我的经验，它应该是您要扩展的可用区数量的 2 倍左右。即使如此，您也可能会看到负载不平衡 - 看到负载在后端队列中精确缩放是非常不寻常的。
您可以通过在不同区域运行 jmeter 实例来提供帮助（一点）。
另一个因素是测试的持续时间。 ELB 确实需要一些时间来扩展 - 您通常可以通过对 ELB 名称进行 nslookup 来了解正在运行的实例数量。了解您的扩展模式，并围绕它们构建测试。 （因此，如果需要 20 分钟才能将另一个实例添加到 ELB 池，请为您的测试提供 25-30 分钟的预热时间。）如有必要，您还可以让 AWS 来“预热”ELB 池。
如果您的 ELB 池大小足以满足您的测试，并且可以验证池在测试运行期间不会更改，您始终可以尝试直接针对 ELB IP 运行测试 - 即手动平衡流量。
我不确定您期望第二层调用发生什么 - 如果您打开连接并重新使用它，显然没有办法在不关闭和关闭连接的情况下跨实例扩展连接。重新打开连接。这些调用是在同一组服务器上运行还是在不同的服务器组上运行？您可以创建一个内部 ELB，并使用该端点进行连接，但我不确定这对您描述的场景是否有帮助。
You don't say how many jmeter instances you're running, but in my experience it should be around 2x the number of AZs you're scaling across. Even then, you will probably see unbalanced loads - it is very unusual to see the load scaled exactly across your back-end fleet.
You can help (a bit) by running your jmeter instances in different regions.
Another factor is the duration of your test. ELBs do take some time to scale up - you can generally tell how many instances are running by doing an nslookup against the ELB name. Understand your scaling patterns, and build tests around them. (So if it takes 20 minutes to add another instance to the ELB pool, include a 25-30 minute warm-up to your test.) You also get AWS to "pre-warm" the ELB pool if necessary.
If your ELB pool size is sufficient for your test, and can verify that the pool does not change during a test run, you can always try running your tests directly against the ELB IPs - i.e. manually balancing the traffic.
I'm not sure what you expect to happen with the 2nd tier of calls - if you're opening a connection, and re-using it, there's obviously no way to have that scaled across instances without closing & re-opening the connection. Are these calls running on the same set of servers, or a different set? You can create an internal ELB, and use that endpoint to connect to, but I'm not sure that would help in the scenario you've described.