本文介绍了AWS Elastic Load Balancing:查看极长的初始连接时间的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

它不会发生每一次请求,但会发生大约50%的请求。它发生在第一个请求(OPTIONS-call)中。



我们的设置如下:
连接到node.js后端的跨域ELB目前位于欧盟西部1区的2个亚利桑那州)。所有实例都是健康的,一旦请求通过,它就会正常处理。目前,系统基本没有负载。 CloudBatch for ELB不报告任何后端连接错误,SurgeQueue(0值)和溢出计数。 ELB度量显示低延迟(我们将Route53配置为路由到ELB(我们没有看到任何dns的麻烦,请参阅附加的屏幕截图)。

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



ELB还可以执行SSL终止。

什么会导致这种行为? ELB可能配置不正确吗?为什么它只能出现在Google Chrome上?

>

解决方案

我认为这是一个可能的ELB错误配置。当我将私有子网放入ELB时,我遇到了同样的问题。通过将私有子网更改为公共来修复它。请参阅


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).

It does not occur every single request, but around 50% of requests. It occurs with the first request (OPTIONS-call).

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).

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.

The ELBs also do our SSL-termination.

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?

解决方案

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:查看极长的初始连接时间的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

10-11 03:03