Спасибо, Максим!
Да, тестово получилось повторить, дело действительно в delayed Ack.
On 9/4/20 6:38 PM, Maxim Dounin wrote:
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
по умолчанию на линуксе, так что скорее всего оно.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
