O que indica exactamente o campo" Tempo " no registo?

estive a estudar os ficheiros de log de formato W3C no IIS 7.5 durante algum tempo num servidor com alguns problemas de desempenho, e parece-me que, ao contrário da documentação MSDN, o campo "Tempo" é não

"o tempo, em tempo Universal Coordenado (UTC), no qual o pedido ocorreu"

... mas é o momento em que a resposta foi enviada.

Digo isto porque quando sigo a sequência da página pedido de usuários em um ambiente um tanto controlado, eles teriam que estar voltando no tempo para submeter o próximo pedido, ou então eles são capazes de submeter seus pedidos de páginas chocantemente rápido para uma página com uma entrada de tempo grande.

por exemplo (e estou a redactorar, a abreviar e a omitir, para segurança e clareza):

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip sc-status sc-substatus sc-win32-status time-taken
2012-11-28 22:25:17 192.168.0.21 GET /Main.aspx - 80 AWalker 192.168.0.100 200 0 0 764
2012-11-28 22:25:26 192.168.0.21 POST /Main.aspx - 80 AWalker 192.168.0.100 200 0 0 109
2012-11-28 22:25:56 192.168.0.21 GET /_Start.aspx - 80 AWalker 192.168.0.100 302 0 0 28782
2012-11-28 22:26:33 192.168.0.21 GET /Action.aspx - 80 AWalker 192.168.0.100 200 0 0 38032
2012-11-28 22:26:46 192.168.0.21 POST /Action.aspx - 80 AWalker 192.168.0.100 200 0 0 124
2012-11-28 22:27:39 192.168.0.21 GET /Information.aspx - 80 AWalker 192.168.0.100 200 0 0 52509
2012-11-28 22:27:52 192.168.0.21 POST /Information.aspx - 80 AWalker 192.168.0.100 200 0 0 140

Se eu interpretar o "tempo " como" pedido recebido " (tanto o início como o fim, mas antes que a resposta comece), então isto parece errado. Eis o que quero dizer:

• às 22: 25: 17, O GET for / Main.aspx foi recebido, e levou 764ms para entregar a resposta, o que significa que a resposta não terminou até 14:25:17.764.
• às 14: 25: 26, O posto para / Main.aspx foi recebido. Oito segundos depois da resposta anterior ter terminado. Foram precisos 109ms para dar esta resposta, terminando às 14:25:26.109.
• às 14: 25: 56, O GET for / _Start.aspx foi recebido. Isso é quase 30 segundos após a resposta anterior concluido. Isto parece apropriado; o usuário pode ter estudado Main.aspx antes de carregar no link para _iniciar.aspx. Foi preciso, estranhamente, quase 29 segundos para entregar esta resposta de redirecionamento 302 (28782ms), terminando às 14:26:24.782. Mas é por isso que estou a ver os registos, para descobrir porquê.
• às 14: 26: 33, O GET for / Action.aspx foi recebido. Isso é cerca de 8 segundos após a resposta anterior terminar. Isso parece apropriado (8 segundos de tempo de resposta do Usuário). A resposta foi de 38032ms (demasiado long, daí a investigação), e terminou às 14: 27: 11.032.
• às 14: 26: 46, O posto de acção.aspx foi recebido. São 8,2 segundos antes de a resposta anterior terminar. Sim, estou plenamente ciente de que os usuários nem sempre têm que esperar pela página para renderizar completamente antes de clicar em um link para obter a próxima página, ou pressionando Refresh, mas isso acontece muito, mesmo para pedidos muito mais curtos. A resposta levou 124ms, terminando às 14: 26: 46.124.
• às 14: 27: 39, a oportunidade para /Informacao.aspx foi recebido. São 52,9 segundos após a resposta anterior ter terminado. Isso parece um pouco longo, desde que os testadores foram instruídos a atingir o sistema o mais forte que puderam, mas não é inapropriadamente longo. A resposta levou 52509ms (quase exatamente 52,9 segundos!), terminando às 14: 28: 31.509. É uma coincidência muito estranha que acontece. Muito frequentemente Se eu interpretar o campo de tempo como " pedido recebido."
• às 14: 27: 52, O posto de /Informacao.aspx foi recebido. São 39,5 segundos antes de a resposta anterior terminar.

Este tipo de padrão continua a ir, vezes sem conta, nos registos.

por outro lado, Se eu interpretasse o campo " Tempo "como significando" resposta terminada", então eu teria números sâneres:

• por volta das 14: 25: 16.236( 764ms antes das 14: 25: 17), O GET for / Main.aspx foi recebido, e levou 764ms para entregar, terminando a resposta às 14:25:17.
• por volta de 14: 25: 25.891, o posto para / Main.aspx foi recebido. Isso é cerca de 8,9 segundos após a resposta anterior terminar. Foram precisos 109ms para dar esta resposta, terminando às 14: 25: 26.
• por volta das 14: 25: 27.218, o lançamento para / _iniciar.aspx foi recebido. São 1,2 segundos após a resposta anterior ter terminado. Isso é rápido para uma resposta do usuário, mas não muito para esses Testadores bem treinados navegando através de um menu bem conhecido. A resposta levou 28.782 ms (muito tempo, mas esta é a causa para o análise de desempenho), e terminou às 14: 25: 56.
• por volta das 14: 25: 54.968, O "GET for / Action".aspx foi recebido. Isso é cerca de 1.0 segundo antes de a resposta anterior ter terminado. Pode ser um erro de arredondamento, já que o campo de tempo não captura milisegundos. A resposta levou 38032ms, e foi concluída às 14:26:33.
• por volta das 14: 26: 45.876, o POST para / acção.aspx foi recebido. Isso é cerca de 12,9 segundos após a resposta anterior terminar. É bonito. normal para um tempo de resposta do utilizador. A resposta levou 124ms, e foi concluída às 14:26:46.
• por volta das 14: 26: 46.491, O GET for / Information.aspx foi recebido. Isso foi cerca de 0,5 segundos após a resposta anterior terminar. Isso pode ser um redirecionamento iniciado por script ou um usuário rápido. A resposta levou 52509ms, e terminou às 14:27:39. Página lenta.
• por volta das 14: 27: 51.860, o POST para / informação.aspx foi recebido. Isto foi cerca de 12,9 segundos após a resposta anterior. concluido. Tempo de resposta Normal do utilizador (coincidentemente igual ao POST anterior). A resposta levou 140 mm, e terminou às 14:27:52.

a outra razão pela qual faz mais sentido para mim que o campo "Tempo" representa o fim da resposta, em vez do início do pedido, é esta:

as entradas de registo são registadas fisicamente na ordem ascendente do Campo "tempo" (cronologicamente ordenado), mas incluem sempre o campo" tempo tomado", que só poderia ser conhecido após {[7] } a resposta foi finalmente entregue.

Então, para que lado é? A documentação está errada?