Hello!

On Fri, Sep 04, 2020 at 01:33:18PM +0300, Panichev Oleg wrote:

> При включении keepalive в секции upstream для fastcgi серверов
> upstream_response_time увеличивается на 40мс при нагрузке. Это
> достаточно четкий шаг,
> реальный ответ бэкендову нас - единицы миллисекунд, но nginx
> показывает на 40мс больше.  Apache benchmark tool показывает
> тоже самое.
>
> С чем связана именно такая задержка? Изменения таймаутов,
> количества реквестов на эти 40мс не влияют, в логе всегда либо
> единицы миллисекунд (время ответа
> для простых соединений, без включения keepalive), либо сразу
> 40мс+время простого запроса. Есть ли способ измерять реальное
> время ответа от бэкенда при
> использовании keepalive?

Смотрите tcpdump между nginx'ом и бэкендом, возможно станет
понятнее, что происходит. Возможные направления, куда, как мне
кажется, имеет смысл копать:

1. Keepalive в случае FastCGI означает, что nginx'у надо
дожидаться не просто закрытия stdout-потока, но и записи
FCGI_END_REQUEST. Если вдруг бэкенд её посылает с задержкой - это
может быть причиной.

2. FastCGI - сложный протокол, и бэкенд может наступать на
классическую проблему delayed ack vs. Nagle. Ну и это хорошо
сочетается с предыдущим пунктом, скажем - если запись
FCGI_END_REQUEST бэкенд шлёт отдельной записью в сокет, то реально
отправится она только по получению ack'а на предыдущую запись, а
тот в свою очередь придёт только по истечению таймаута delayed
ack. Обычно для тестов проще всего отключить delayed ack
глобально на машине, и посмотреть, не починится ли. Лечить
правильно - либо грамотной работой с сокетами (не допускать
паттерна write+write+read), либо выставлением на сокет
TCP_NODELAY.

Ну и да, гугл подсказывает, что 40ms - задержка delayed ack
по умолчанию на линуксе, так что скорее всего оно.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru