Nginx с node и lingering_close, поддерживающими соединение в течение 5 секунд

У нас есть набор серверов, настроенных для использования нашего нового блестящего API, который заменит наш старый API, написанный на загадочном языке.

Новое приложение представляет собой кластер серверов, использующих узел, сразу за NGINX.

Это кластер того же типа, что и для старого API.

Есть еще один сервер, сидящий в фонде этих двух кластеров, использующий NGINX для маршрутизации трафика к одному или другому.

Прямо сейчас новый кластер получает гораздо меньше 1% трафика, в то время как старый кластер получает гораздо более 99% трафика.

Журналы показывают, что клиент (клиент, сидящий перед Маршрутизатор NGINX) всегда получает ответы своевременно (независимо от того, какой кластер обрабатывает запрос)

Журналы также показывают, что узел своевременно отвечает на свой локальный NGINX.

Старый NGINX / API работает хорошо.

Однако ЛОКАЛЬНЫЕ NGINX для кластера узлов регистрируют, что каждый запрос занимает время, необходимое узлу для ответа ... плюс дополнительные 5 секунд.

Небольшое расследование доказывает, что это связано с параметром конфигурации lingering_close ..., который установлен на 5 секунд. Согласно документации, задержка закрытия использует «эвристику», чтобы решить, когда оставаться открытым.

http://nginx.org/en/docs/http/ngx_http_core_module.html#lingering_close

Это более чем расплывчато.

Мы знаем, что соединение остается открытым только в течение 5 секунд, когда ответы меньше 1,1k. Я знаю, что это странно ... но «Эвристика»

Если мы отключим lingering_close ... соединения закрываются без воздействия эвристики.

Похоже, этого никогда не происходит в СТАРЫМ кластере.

У кого-нибудь есть любую более четкую информацию о том, какая эвристика может поддерживать соединение, и, возможно, несколько советов о том, как действовать.

меня больше всего беспокоит то, что весь трафик перемещается во второй кластер, и все эти открытые соединения начинают вызывать проблемы с производительностью.