Hello!
On Fri, Mar 27, 2020 at 08:18:10AM -0400, opan wrote:
> Добрый день!
>
> 1. В данном случае мы видели содержимое и ответ умещался в один пакет
> 2. У нас есть метрики на самом бэкенде, где мы засекаем время ответа. в 90%
> оно составляет меньше <1 мс, в то время как 90 персентиль по
Добрый день!
1. В данном случае мы видели содержимое и ответ умещался в один пакет
2. У нас есть метрики на самом бэкенде, где мы засекаем время ответа. в 90%
оно составляет меньше <1 мс, в то время как 90 персентиль по логам нжинкса
получается 45мс.
Не может нджинкс возвращать неправильный
On Wed, Mar 25, 2020 at 09:48:10AM -0400, opan wrote:
> Добрый день.
>
> В продолжение изучения проблемы обнаружили что в логе нжинкса
> upstream_response_time - 41ms, а этот же запрос, если смотреть tcpdump,
> время ответа бэка меньше 1ms:
>
>
Добрый день.
В продолжение изучения проблемы обнаружили что в логе нжинкса
upstream_response_time - 41ms, а этот же запрос, если смотреть tcpdump,
время ответа бэка меньше 1ms:
https://www.dropbox.com/s/04falc2m073jnf5/Screenshot%202020-03-25%2016.38.15.png?dl=0
Как такое может быть?
On
1. Про ssl верно, мы замеряли сколько времени занимает установка соединения.
Это 20-30мс, не больше.
2. Пробовали, не помогает
Во всем этом самое странное, что время ответа через прокси и напрямую
примерно одинаковое, хотя если верить upstream_response_time оно должно быть
сильно больше через
пара моментов
1) у вас proxy_pass на https, по крайней мере первоначальный хендшейк может
быть долгим (например, если клиент захочет сделать OCSP проверку). выглядит
так, как будто у вас
должен быть кипэлайв до бекенда, поэтому это соображение должно касаться
только редких запросов
2) возможно,
У нас есть одна площадка, нжинкс принимает запросы и проксирует на бэкенд
через fcgi_pass. В логах нжинса мы видим upstream_response_time 40мс.
Появилась вторая площадка, мы принимаем там трафик и отправляем все на
первую площадку через proxy_pass. Так же логируем здесь
upstream_reponse_time и
