А как тогда может получаться ноль? Если это время - заведомо большедесяти
миллисекунд?
On 11/14/05, Igor Sysoev <is@xxxxxxxxxxxxx> wrote:> 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 не пытается измерить время точно.>>> Игорь Сысоев>
>>
--Alexey Polyakov
