AWS Elastic Load Balancing：看到极长的初始连接时间

Question

在几天内，我们经常会在通过ssl发出任何请求时看到我们的ELB的初始连接时间非常长（15s - 1.3分钟）。 奇怪的是，我只能在谷歌浏览器中观察到这一点（不是Safari，也不是Firefox，也不是卷曲）。

每次请求都不会发生，但大约有50％的请求。它发生在第一个请求（OPTIONS-call）。

我们的设置如下： 连接到node.js后端的跨区ELB（目前在eu-west-1中的2个AZ中）。所有实例都是健康的，一旦请求通过，它就会正常处理。目前，系统基本上没有负载。 Cloudwatch for ELB不会报告任何后端连接错误，也不会报告SurgeQueue（值0）和溢出计数。 ELB度量显示低延迟（<100ms）。 我们将Route53配置为路由到ELB（我们没有看到任何dns问题，请参阅附带的屏幕截图）。

我们有不同的REST-API都有这个设置。它发生在所有ELB上（每个ELB都连接到一个独立的node.js后端）。所有这些ELB都通过我们的云形态模板以相同的方式设置。

ELB也进行SSL终止。

什么可能导致这种行为？ ELB可能配置不正确吗？为什么它只能出现在谷歌浏览器上？

Answer 1

我认为这可能是ELB错误配置。当我将私有子网放入ELB时，我遇到了同样的问题。通过将私有子网更改为public来修复它。见https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-manage-subnets.html

Answer 2

关注@Nikita Ogurtsov的优秀答案;我遇到了同样的问题，只是 只是我的一个子网 碰巧是私有的，其余的是公开的。

即使您认为您的子网是公开的，我建议您仔细检查路由表，以确保他们 所有 都有一个网关。

如果这有意义，您可以使用具有所有LB子网网关的单个路由表

VPC/Subnets/(select subnet)/Route Table/Edit

Answer 3

这可能是亚马逊榆树的一个问题。 elb使用请求数量缩放实例数。 你应该在那些时候看到一些请求。 亚马逊添加了一些实例以适应负载。 在启动过程中可以访问实例，以便客户端获得超时。它完全随机，所以你应该：

• ping elb以获取所有使用的ip

• 在找到的所有IP上使用mtr

• 密切关注CloudWatch

• 找一些线索

Answer 4

解决方案如果您将DNS配置为直接点击ELB - ＆gt;你应该减少关联的TTL（IP，DNS）。 IP随时可以随ELB发生变化，因此您的流量可能会受到严重损害。

客户端将一些IP保留在缓存中的ELB中，这样就可以解决这些问题。

  

扩展弹性负载均衡器   创建弹性负载均衡器后，必须将其配置为接受传入流量并将请求路由到EC2实例。这些配置参数由控制器存储，控制器确保所有负载平衡器都以正确的配置运行。控制器还将监视负载平衡器并管理用于处理客户端请求的容量。它通过利用更大的资源（具有更高性能特征的资源）或更多的个人资源来增加容量。 Elastic Load Balancing服务将在扩展时更新负载均衡器的域名系统（DNS）记录，以便新资源在DNS中注册其各自的IP地址。创建的DNS记录包括60秒的生存时间（TTL）设置，期望客户端至少每60秒重新查找DNS。默认情况下，Elastic Load Balancing将在客户端执行DNS解析时返回多个IP地址，并在每个DNS解析请求上随机排序记录。随着流量配置文件的更改，控制器服务将扩展负载平衡器以处理更多请求，并在所有可用区中进行相同的扩展。

Best Practices ELB on AWS

Answer 5

还要检查安全组。就我而言，这是一个问题。

Answer 6

对我来说，问题是我的经典负载均衡器中有一个未使用的“可用区”。一旦我删除了不健康且未使用的可用区，“初始连接”中一致的20或21秒延迟就会降至50ms以下。

注意：您可能需要给它一些时间进行更新。我将DNS TTL设置为60秒，因此在删除未使用的可用区后的一分钟内，我会看到此修复程序。

Answer 7

对我来说，问题是ALB指向一个Nginx实例，该实例的DNS解析器配置错误。这意味着Nginx尝试使用解析器，超时，然后稍后实际上开始工作。

与Load Balancer本身并没有真正的超级联系，但也许可以帮助某人在自己的设置中找出问题所在。

Answer 8

ALB 负载均衡器需要 2 个可用区。如果您使用私有/公共/Nat VPC 设置，则所有公共子网都必须连接到 Internet。