【发布时间】：2015-04-28 15:42:51
【问题描述】：
此问题已在 AWS 论坛上提出，但没有任何回应。以下是原问题
嗨！
我们正在对 ELB 后面的 API 实例进行滚动升级，并且在等待连接耗尽完成时看到的时间非常长。场景如下：
我们正在运行两个相同的系统，一个 ELB 后面的 4x c3.large，一个用于开发的系统和一个用于生产的系统。这两个系统的唯一区别是生产系统不断地服务请求。
在没有流量的情况下，所有 4 个实例的开发系统滚动升级大约需要 3 分钟。在生产系统上，这些时间在 6 到 17+ 分钟之间波动。由于某些原因，我们需要平均每小时进行 2 次左右的滚动升级，然后滚动升级超过 17 分钟开始成为问题。
我们所有的 API 调用都小于 100 毫秒，因此没有长时间运行的请求会导致连接流失这么长时间。我们尝试在 ELB 上更改空闲超时和连接耗尽超时的值，但没有得到好的结果。
当降低连接耗尽超时时，我们看到来自 API 的 502 响应，因为它强制断开连接并且降低空闲超时似乎没有效果。
总而言之，我们想知道可以做些什么来减少这些时间。由于我们的请求都小于 100 毫秒，因此理论上应该不超过一两秒来从实例中耗尽连接。我们这里有什么遗漏吗？
最后一点：我们尝试关闭所有连接耗尽，这似乎比降低连接耗尽超时效果更好。平均而言，每次测试运行只有 1 或 2 个错误，有些运行没有错误。这是因为响应时间太快了吗？我们的响应也相对较小，因此 TCP 响应可能保存在 OS 输出缓冲区中，因此即使关闭连接耗尽它也可以响应？将连接耗尽超时设置为 0 和关闭有什么区别？
附加信息：
- 所有流量都是 HTTPS
- SSL 终止发生在实例上
- 在 nginx 上启用了keep-alive（也尝试在此处更改值，但没有任何结果）
谢谢！
【问题讨论】：
-
希望更好地理解这个问题，您是否使用自动伸缩组进行此次升级？因为默认情况下，伸缩组使用实例健康状态而不是 elb 检查状态来确定 ec2 是否健康。因此，默认缩放可能需要更长的时间。
-
请添加指向 AWS 论坛帖子的链接。
标签： amazon-web-services nginx amazon-elb aws-ec2