我们有一系列的服务器设置使用我们新的shiny的API，它将取代我们以古老的语言编写的旧API。
新应用程序是一个使用节点的服务器集群，位于NGINX之后。
这是为旧的API设置的相同types的集群。
还有另一台服务器坐在这两个集群的字体中，使用NGINX将stream量路由到一个或另一个。
目前，新集群的stream量远低于1％，而旧集群的stream量超过99％。
日志表明客户端（坐在NGINX路由器前面的客户端）总是及时接收响应（无论哪个集群处理请求）
日志还表明节点正在及时响应本地的NGINX。
旧的NGINX / API运行良好。
但是，节点集群的LOCAL NGINX正在logging每个请求所花费的时间，以使节点响应…加上额外的5秒钟。
有一点调查certificate，这是由于configuration设置称为lingering_close …它被设置为5秒。 根据文件，持续closures使用“启发式”决定何时保持开放。
http://nginx.org/en/docs/http/ngx_http_core_module.html#lingering_close
这是比较模糊的。
我们知道当响应小于1.1k时，连接只保持5秒。 我知道这很奇怪，但“启发式”
如果我们将lingering_closeclosures…连接closures没有启发式的影响。
这似乎从来没有发生在旧的群集。
有没有人有任何启发式可能保持连接的更清楚的信息，并可能有一些build议如何进行。
我最担心的是，所有的stream量都被转移到了第二个集群，所有这些打开的连接开始引起性能问题。
这是所有关于指示，可以有更多的数据留在套接字中。 例如，如果在处理过程中未完成请求主体读取，或者缓冲区中还有更多数据，或者套接字处于活动状态，则延迟closures被启用。
你可能对这个改变感兴趣，这会显着降低在Linux上closures的可能性： http : //hg.nginx.org/nginx/rev/f7849bfb6d21