У меня есть веб-сайт HTTPS, на котором иногда для одних и тех же клиентов значение $ request_time в 10 раз больше, чем $ upstream_response_time, или даже в 100 раз. Я понимаю разницу между двумя временами: $ request_time - это продолжительность между первым полученным байтом и последним отправленным байтом.
Некоторые пользователи рассказали мне, что у них истекло время ожидания соединения, поэтому я думаю, что эти длинные $ request_time - настоящие проблемы.
Эти длинные $ request_time случаются для запросов GET (типичный размер запроса: 185 байт). Апстрим - это процесс fastcgi. Интересно, при каком сценарии $ request_time может быть слишком большим:
Интересно, какие варианты на самом деле возможны и как мне узнать, что на самом деле создает long $ request_time.
OSCP является проблемой то и дело, но я бы исследовал больше в направлении тайм-аута / недоступности fastcgi-worker. действительно ли это heisenbug или такое случается с разными пользователями? есть ли у вас мониторинг на основе http (например, настоящие GET-запросы через Nagios, Selenium и т. д., а не только порт 80/443 - проверьте)
шаги отладки: