ELB 后面的单个 EC2 会产生巨大的延迟答案

【问题标题】：Single EC2 behind ELB creates massive latencyELB 后面的单个 EC2 会产生巨大的延迟
【发布时间】：2022-01-20 10:54:30
【问题描述】：

我有一个在单个 EC2 实例上运行的 Flask API。我需要将 SSL (https) 添加到我的应用程序中，文档似乎表明最好的方法是使用 ELB。

问题是，当我在 ELB 后面设置 EC2 并且 Route 53 指向负载均衡器时，我遇到了前所未有的延迟问题。 API 调用应该需要 150 毫秒，需要 31 秒。直接ping EC2没有问题，但是ping Route53/ELB时间太长了。

我看过过去的回复，例如：

延迟的原因是因为您设置了 ELB 在其他 2 个可用区中没有任何应用程序实例的多可用区配置。如果这些 AZ 请求中没有实例，则往往会失败因为 ELb 仍然返回那些 AZ 的 IP 地址，即使没有活动的应用程序实例。请禁用其他 AZ 的现在并继续你的测试。

所以我删除了与我的 EC2 实例无关的子网和可用区，但现在我有： 503 errors: Backend server is at capacity 到处都是。

快把我的头发拔掉了。我正在尝试为我的应用设置 SSL...

【问题讨论】：

您是否禁用了跨区域负载平衡？
是的。我禁用了它，因为现在我在 ELB 中只有一个区域。
如果你启用它，延迟会减少吗？
延迟在启用跨区域的情况下仍然相同。有趣的是，如果我将 ELB 设置为具有多个 AZ，我永远不会出现 503 错误，但延迟仍然是一个问题。
您能否为 TargetLatency 指标检查负载均衡器的 CloudWatch 指标。这应该可以帮助您确定延迟是在主机上还是在 LB 上

标签： amazon-web-services amazon-ec2 amazon-elb

【解决方案1】：

对于遇到此问题的其他人，使用 Application Load Balancer 而不是 Classic Load Balancer 已解决此延迟问题。

【讨论】：

【解决方案2】：

似乎有些连接问题。请按照此步骤深入研究问题。因为它只发生在负载均衡器上。所以首先做 NSLOOKUP 之类的 nslookup 名称。您将获得至少两个 IP。

尝试单独 curl LB IP 的 n 检查响应时间。您可以使用以下命令或任何您喜欢的工具。

curl -w "dns_resolution: %{time_namelookup}, \
         tcp_established: %{time_connect}, \
         ssl_handshake_done: %{time_appconnect}, \
         TTFB: %{time_starttransfer}\n" \
         -o /dev/null -s "http://<ELB IP>/<path>"

这样你就可以弄清楚是否是问题所在。这是由于某个特定 AZ 子网的路由问题或其他问题。

【讨论】：