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