问题描述
在几天内，通过 ssl 发出任何请求时，我们经常看到与 ELB 的初始连接时间非常长(15 秒 - 1.3 分钟).奇怪的是，我只能在 Google Chrome(不是 Safari、Firefox 或 curl)中观察到这一点.
For a couple of days, we often see an extremely long initial connection time (15s - 1.3 minutes) to our ELBs when making any request via ssl. Oddly, I was only able to observe this in Google Chrome (not Safari nor Firefox nor curl).
它不会出现在每一个请求中，而是发生在大约 50% 的请求中.它发生在第一个请求(OPTIONS 调用)中.
It does not occur every single request, but around 50% of requests. It occurs with the first request (OPTIONS-call).
我们的设置如下:连接到 node.js 后端的跨区域 ELB(目前在 eu-west-1 的 2 个可用区).所有实例都是健康的，一旦请求通过，就会正常处理.目前，系统基本没有负载.ELB 的 Cloudwatch 不报告任何后端连接错误，既不报告 SurgeQueue(值 0)也不报告溢出计数.ELB 指标显示低延迟(
Our setup is the following:Cross-Zone ELB that connects to a node.js backend (currently in 2 AZs in eu-west-1). All instances are healthy and once the request comes through, it is processed normally. Currently, there is basically no load on the system. Cloudwatch for ELB does not report any backend connection errors, neither a SurgeQueue (value 0) nor a spillover count. The ELB metrics show a low latency (< 100 ms).We have Route53 configured to route to the ELB (we don't see any dns trouble, see attached screenshot).
我们有不同的 REST-API，它们都具有此设置.它发生在所有 ELB 上(每个 ELB 都连接到一个独立的 node.js 后端).所有这些 ELB 都是通过我们的 cloudformation 模板以相同的方式设置的.
We have different REST-APIs that all have this setup. It occurs to all of the ELBs (each of them is connecting to an indipendent node.js backend). All of these ELBs are set up the same way via our cloudformation template.
ELB 也执行我们的 SSL 终止.
The ELBs also do our SSL-termination.
什么会导致这种行为?是否有可能是 ELB 没有正确配置?为什么它只能出现在谷歌浏览器上?
What could lead to such a behavior? Is it possible that the ELBs are not configured properly? And why could it only appear on Google Chrome?
推荐答案
我认为这可能是 ELB 配置错误.当我将私有子网放入 ELB 时，我遇到了同样的问题.通过将私有子网更改为公共子网来修复它.请参阅 https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-manage-subnets.html
I think it is a possible ELB misconfiguration. I had the same problem when I put private subnets to ELB. Fixed it by changing private subnets to public. See https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-manage-subnets.html
这篇关于AWS Elastic Load Balancing:看到极长的初始连接时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！