我们设立了一组服务器来使用我们新的闪亮 API，它们将取代我们用神秘语言编写的旧 API。
新的应用程序是一个使用节点的服务器集群，紧随 NGINX 之后。
这与为旧 API 设置的集群类型相同。
这两个集群前面还有另一台服务器，使用 NGINX 将流量路由到其中一个集群。
目前，新集群接收的流量远低于 1％，而旧集群接收的流量远高于 99％。
日志表明客户端（位于 NGINX 路由器前面的客户端）始终及时收到响应（无论哪个集群处理请求）
日志还表明节点正在及时响应其本地 NGINX。
旧的 NGINX/API 运行良好。
但是，节点集群的本地 NGINX 正在记录每个请求所需的时间，以及节点响应所需的时间......再加上额外的 5 秒。
经过一番调查，我们发现这是由于名为 lingering_close... 的配置设置导致的，该设置设置为 5 秒。根据文档，lingering close 使用“启发式”来决定何时保持打开状态。
http://nginx.org/en/docs/http/ngx_http_core_module.html#lingering_close
这实在是太模糊了。
我们知道，当响应小于 1.1k 时，连接只会保持 5 秒。我知道这很奇怪……但是“启发式”
如果我们关闭 lingering_close...连接将关闭，并且不会受到启发式方法的影响。
这似乎从未在旧集群上发生过。
是否有人能更清楚地了解哪些启发式方法可以保持连接畅通，以及可能的一些有关如何进行的建议。
我最担心的是所有流量都转移到第二个集群，并且所有这些开放的连接开始导致性能问题。
答案1
这都是为了表明套接字中可能还剩下更多数据。例如，如果在处理过程中未读取完整的请求主体，或者缓冲区中还剩下一些数据，或者套接字处于活动状态，则启用延迟关闭。
您可能会对这个变化感兴趣，它大大降低了在 Linux 上徘徊关闭的概率：http://hg.nginx.org/nginx/rev/f7849bfb6d21