Re: upstream fastcgi keepalive. Таинственные 40мс

2020-09-06 Пенетрантность Panichev Oleg 

Спасибо, Максим!


Да, тестово получилось повторить, дело действительно в 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

Re: upstream fastcgi keepalive. Таинственные 40мс

2020-09-04 Пенетрантность Maxim Dounin 
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

Re: upstream fastcgi keepalive. Таинственные 40мс

2020-09-04 Пенетрантность Panichev Oleg 

Пинг в продакшн быстрый: rtt min/avg/max/mdev = 0.054/0.095/0.131/0.027 ms
Примеры, приведенные выше, вообще делаются на одном сервере (localhost:9000)

Протокол fastcgi.


On 9/4/20 3:29 PM, fox wrote:

Пинг до сервера какой? Протокол http 1.1?


04.09.2020 18:22, Panichev Oleg пишет:

В данном случае, с пустым конфигом и php-fpm, зависимости либо нет, либо
она незаметна:


keepalive 1:

Percentage of the requests served within a certain time (ms)
   50%  3
   66%  3
   75% 41
   80% 43
   90% 44
   95% 44
   98% 44
   99% 44
  100% 55 (longest request)

keepalive 100:

   50%  3
   66%  3
   75%  4
   80% 42
   90% 43
   95% 44
   98% 44
   99% 45

  100% 47 (longest request)



On 9/4/20 2:07 PM, Сергей Олегович wrote:

Интересно, а есть ли зависимость между количеством keepalive и временем?

пт, 4 сент. 2020 г. в 13:33, Panichev Oleg mailto:panic...@rutarget.ru>>:

 Добрый день.


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

 С чем связана именно такая задержка? Изменения таймаутов, количества
 реквестов на эти 40мс не влияют, в логе всегда либо единицы
 миллисекунд
 (время ответа для простых соединений, без включения keepalive), либо
 сразу 40мс+время простого запроса. Есть ли способ измерять реальное
 время ответа от бэкенда при использовании keepalive?

 Спасибо, ниже конфиги и результаты ab.


 ===

 Пробовал на свежем нджинксе и стартовой странице php-fpm:

 Проверка с keepalive:

  upstream sync {
     server localhost:9000;
     keepalive 8;
  }

 ..

  location ~ \.php$ {
  fastcgi_pass sync;
  fastcgi_keep_conn on;
 ...

 Percentage of the requests served within a certain time (ms)
    50%  3
    66%  3
    75%  4
    80% 42
    90% 43
    95% 44
    98% 44
    99% 45
   100% 52 (longest request)
 ==

 Без keepalive тот же апстрим:

 Percentage of the requests served within a certain time (ms)
    50%  1
    66%  1
    75%  1
    80%  1
    90%  1
    95%  2
    98%  2
    99%  3
   100%  7 (longest request)

 Это повторяется на разных приложениях и разных фронтендах (см.
 скриншот)



 ___
 nginx-ru mailing list
 nginx-ru@nginx.org 
 http://mailman.nginx.org/mailman/listinfo/nginx-ru


___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru


___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: upstream fastcgi keepalive. Таинственные 40мс

2020-09-04 Пенетрантность fox 
Пинг до сервера какой? Протокол http 1.1?


04.09.2020 18:22, Panichev Oleg пишет:
> В данном случае, с пустым конфигом и php-fpm, зависимости либо нет, либо
> она незаметна:
> 
> 
> keepalive 1:
> 
> Percentage of the requests served within a certain time (ms)
>   50%  3
>   66%  3
>   75% 41
>   80% 43
>   90% 44
>   95% 44
>   98% 44
>   99% 44
>  100% 55 (longest request)
> 
> keepalive 100:
> 
>   50%  3
>   66%  3
>   75%  4
>   80% 42
>   90% 43
>   95% 44
>   98% 44
>   99% 45
> 
>  100% 47 (longest request)
> 
> 
> 
> On 9/4/20 2:07 PM, Сергей Олегович wrote:
>> Интересно, а есть ли зависимость между количеством keepalive и временем?
>>
>> пт, 4 сент. 2020 г. в 13:33, Panichev Oleg > >:
>>
>> Добрый день.
>>
>>
>> При включении keepalive в секции upstream для fastcgi серверов
>> upstream_response_time увеличивается на 40мс при нагрузке. Это
>> достаточно четкий шаг, реальный ответ бэкендову нас - единицы
>> миллисекунд, но nginx показывает на 40мс больше.  Apache benchmark
>> tool
>> показывает тоже самое.
>>
>> С чем связана именно такая задержка? Изменения таймаутов, количества
>> реквестов на эти 40мс не влияют, в логе всегда либо единицы
>> миллисекунд
>> (время ответа для простых соединений, без включения keepalive), либо
>> сразу 40мс+время простого запроса. Есть ли способ измерять реальное
>> время ответа от бэкенда при использовании keepalive?
>>
>> Спасибо, ниже конфиги и результаты ab.
>>
>>
>> ===
>>
>> Пробовал на свежем нджинксе и стартовой странице php-fpm:
>>
>> Проверка с keepalive:
>>
>>  upstream sync {
>>     server localhost:9000;
>>     keepalive 8;
>>  }
>>
>> ..
>>
>>  location ~ \.php$ {
>>  fastcgi_pass sync;
>>  fastcgi_keep_conn on;
>> ...
>>
>> Percentage of the requests served within a certain time (ms)
>>    50%  3
>>    66%  3
>>    75%  4
>>    80% 42
>>    90% 43
>>    95% 44
>>    98% 44
>>    99% 45
>>   100% 52 (longest request)
>> ==
>>
>> Без keepalive тот же апстрим:
>>
>> Percentage of the requests served within a certain time (ms)
>>    50%  1
>>    66%  1
>>    75%  1
>>    80%  1
>>    90%  1
>>    95%  2
>>    98%  2
>>    99%  3
>>   100%  7 (longest request)
>>
>> Это повторяется на разных приложениях и разных фронтендах (см.
>> скриншот)
>>
>>
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org 
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: upstream fastcgi keepalive. Таинственные 40мс

2020-09-04 Пенетрантность Panichev Oleg 
В данном случае, с пустым конфигом и php-fpm, зависимости либо нет, либо 
она незаметна:



keepalive 1:

Percentage of the requests served within a certain time (ms)
  50%  3
  66%  3
  75% 41
  80% 43
  90% 44
  95% 44
  98% 44
  99% 44
 100% 55 (longest request)

keepalive 100:

  50%  3
  66%  3
  75%  4
  80% 42
  90% 43
  95% 44
  98% 44
  99% 45

 100% 47 (longest request)



On 9/4/20 2:07 PM, Сергей Олегович wrote:

Интересно, а есть ли зависимость между количеством keepalive и временем?

пт, 4 сент. 2020 г. в 13:33, Panichev Oleg >:


Добрый день.


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

С чем связана именно такая задержка? Изменения таймаутов, количества
реквестов на эти 40мс не влияют, в логе всегда либо единицы
миллисекунд
(время ответа для простых соединений, без включения keepalive), либо
сразу 40мс+время простого запроса. Есть ли способ измерять реальное
время ответа от бэкенда при использовании keepalive?

Спасибо, ниже конфиги и результаты ab.


===

Пробовал на свежем нджинксе и стартовой странице php-fpm:

Проверка с keepalive:

 upstream sync {
    server localhost:9000;
    keepalive 8;
 }

..

 location ~ \.php$ {
 fastcgi_pass sync;
 fastcgi_keep_conn on;
...

Percentage of the requests served within a certain time (ms)
   50%  3
   66%  3
   75%  4
   80% 42
   90% 43
   95% 44
   98% 44
   99% 45
  100% 52 (longest request)
==

Без keepalive тот же апстрим:

Percentage of the requests served within a certain time (ms)
   50%  1
   66%  1
   75%  1
   80%  1
   90%  1
   95%  2
   98%  2
   99%  3
  100%  7 (longest request)

Это повторяется на разных приложениях и разных фронтендах (см.
скриншот)



___
nginx-ru mailing list
nginx-ru@nginx.org 
http://mailman.nginx.org/mailman/listinfo/nginx-ru


___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: upstream fastcgi keepalive. Таинственные 40мс

2020-09-04 Пенетрантность Сергей Олегович 
Интересно, а есть ли зависимость между количеством keepalive и временем?

пт, 4 сент. 2020 г. в 13:33, Panichev Oleg :

> Добрый день.
>
>
> При включении keepalive в секции upstream для fastcgi серверов
> upstream_response_time увеличивается на 40мс при нагрузке. Это
> достаточно четкий шаг, реальный ответ бэкендову нас - единицы
> миллисекунд, но nginx показывает на 40мс больше.  Apache benchmark tool
> показывает тоже самое.
>
> С чем связана именно такая задержка? Изменения таймаутов, количества
> реквестов на эти 40мс не влияют, в логе всегда либо единицы миллисекунд
> (время ответа для простых соединений, без включения keepalive), либо
> сразу 40мс+время простого запроса. Есть ли способ измерять реальное
> время ответа от бэкенда при использовании keepalive?
>
> Спасибо, ниже конфиги и результаты ab.
>
>
> ===
>
> Пробовал на свежем нджинксе и стартовой странице php-fpm:
>
> Проверка с keepalive:
>
>  upstream sync {
> server localhost:9000;
> keepalive 8;
>  }
>
> ..
>
>  location ~ \.php$ {
>  fastcgi_pass sync;
>  fastcgi_keep_conn on;
> ...
>
> Percentage of the requests served within a certain time (ms)
>50%  3
>66%  3
>75%  4
>80% 42
>90% 43
>95% 44
>98% 44
>99% 45
>   100% 52 (longest request)
> ==
>
> Без keepalive тот же апстрим:
>
> Percentage of the requests served within a certain time (ms)
>50%  1
>66%  1
>75%  1
>80%  1
>90%  1
>95%  2
>98%  2
>99%  3
>   100%  7 (longest request)
>
> Это повторяется на разных приложениях и разных фронтендах (см. скриншот)
>
>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru