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