ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Нулевой upstream_response_time



On Mon, 14 Nov 2005, Alexey Polyakov wrote:

То есть (2)-(1) - это время, через которое бекенд начал отвечать?
Я думал, что это время, которое бекенд затратил на передачу целиком ответа.

Нет, (2) - это время когда nginx закрыл соединение с бэкендом.
Между (1) и (2) должен быть как минимум один вызов kevent() и gettimeofday().

On 11/14/05, Igor Sysoev <is@xxxxxxxxxxxxx> wrote:
On Sun, 13 Nov 2005, Alexey Polyakov wrote:

Наблюдаю у себя такую странность:
сайт индексируется htdig'ом, который валит подряд много запросов к
страницам, бекенд - Апач/PHP.
Для многих из них в лог пишется 0.000 в качестве значения
upstream_response_time.
Реально же, при тесте например с помощью ab, processing time на таких
страницах никогда не меньше 10-12мс.
ОС - FreeBSD 5.4, nginx - 0.3.7.
С чем подобное поведение может быть связано?

$upstream_response_time считается так:

1) kevent() возвращает новые события, nginx запоминает время (1) в ms.
2) nginx принимает соединение, читает запрос, определяет, что запрос
   уходит к прокси, запоминает текущее время (1).
3) nginx соединяется с бэкендом, если это localhost, то соединение
   устанавливается сразу же. Если нет, то факт соединения возвращается
   через kevent().
4) nginx передаёт запрос и ждёт ответ.
5) наличие ответа возвращается через kevent(), nginx опять запоминает
   время (2).
6) если овет передан полностью, то $upstream_response_time равен (2)-(1).

Как видно, nginx не пытается измерить время точно.


Игорь Сысоев
http://sysoev.ru




 




Copyright © Lexa Software, 1996-2009.