sun*_*ant 24 amazon-web-services amazon-elb
我很想知道CloudWatch提供的ELB Latency Statistic究竟是什么意思.
根据文件:
我不是100%明确的是,在将响应转移到客户端之前,响应是否被缓冲到ELB?
文档中的陈述是否意味着:
要么:
我想了解一个糟糕的最大延迟CloudWatch指标是否可以通过在有线3G连接上拥有大量用户来解释,或者,如果它反而表明应用服务器偶尔会出现响应放缓的潜在问题.
sun*_*ant 22
根据AWS支持:
由于ELB(当配置了HTTP侦听器时)充当代理(请求头进入并得到验证,然后发送到后端),一旦将头发送到后端,延迟度量将开始滴答,直到后端发送第一个字节响应.
如果是POST(或客户发送附加数据时的任何HTTP方法),即使客户上传数据(因为后端需要发送响应的完整请求),延迟也会下降,并且一旦后端发送就会停止输出第一个字节的响应.因此,如果您的客户端发送数据速度较慢,则延迟将考虑上传时间+后端响应时间.
它似乎是衡量服务器从ELB的角度生成响应所花费的时间,而不考虑ELB将响应返回给客户端需要多长时间.
我通过在我的一个应用程序中查看自己的日志来得出这个结论,该应用程序在另一个负载均衡器HAProxy前面使用ELB,而HAProxy又在实际的应用程序服务器之前.(这可能看起来多余,但与仅使用ELB或仅使用HAProxy相比,它提供了几个优势.)
这是我所指的设置:
ELB -->>-- EC2+HAProxy -->>-- EC2+Nginx (multipe instances)
Run Code Online (Sandbox Code Playgroud)
HAProxy 在每个请求上记录多个时间度量标准,包括一个名为Tr
.
Tr:服务器响应时间(仅限HTTP模式). 这是从建立到服务器的TCP连接到服务器发送完整响应头之间经过的时间.它纯粹显示了它的请求处理时间,没有因数据传输而产生的网络开销.
现在,请与我一起解释为什么这里有关于HAProxy正在做什么的讨论与ELB和Latency指标有关.
即使HAProxy记录了许多与代理在每个请求/响应上等待各种事件所花费的时间相关的其他计时器,此Tr
计时器也是我的HAProxy日志中的单个计时器,它与Cloudwatch的"Latency"度量标准记录的值完全对应. ELB在每分钟的基础上,给出或者花费一毫秒或者两分钟......其他的都是变化很大......所以我建议这个ELB指标同样记录你的应用服务器的响应时间,与将响应传递回客户端可能需要的额外时间.
HAProxy和ELB看起来不太可能一致,否则,考虑到HAProxy对定时器的定义,除非ELB的定时器测量与HAProxy测量非常类似的东西,因为这些系统实际上是测量性能在相同的确切请求上相同的应用服务器.
如果您的应用程序服务器没有对自身进行基准测试并记录其自身性能的计时器,您可能需要考虑添加它们,因为(根据我的观察),Latency指标的高值似乎表明您的应用程序可能具有响应性与客户端连接质量无关的问题.
归档时间: |
|
查看次数: |
13113 次 |
最近记录: |