Question

我已经在服务器上研究了IIS 7.5中的W3C格式日志文件一段时间而出现了一些性能问题，在我看来，与MSDN documentation相反，＆＃34;时间＆＃34;字段不

＆＃34;请求发生的时间，协调世界时（UTC）＆＃34;

...而是响应完成发送的时间。

我这样说是因为当我在一个有点受控制的环境中跟踪来自用户的页面请求序列时，他们必须及时返回以提交下一个请求，否则他们能够提交他们对页面的请求令人震惊对于有大量时间输入的页面来说速度很快。

例如（为了安全和清晰起见，我正在编辑，缩写和省略）：

#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

如果我解释＆＃34;时间＆＃34; as＆＃34; 请求＆＃34; （无论是开始还是结束，但在响应开始之前），这看起来都是错误的。这就是我的意思：

在22:25:17，收到了/Main.aspx的GET，并且花了764ms来传递响应，这意味着响应没有完成，直到14：25：17.764。
在14:25:26，收到了/Main.aspx的POST。在上一个响应完成后的8秒钟。花了109ms来完成这个响应，结束于14：25：26.109。
在14:25:56，收到了/_Start.aspx的GET。在前一个响应完成后差不多30秒。这似乎合适;在单击指向_Start.aspx的链接之前，用户可能已经学习过Main.aspx。奇怪的是，差不多29秒才发送302重定向响应（28782ms），结束时间为14：26：24.782。但这就是为什么我要查看日志，找出原因。
在14:26:33，收到了/Action.aspx的GET。在前一个响应完成后大约8秒钟。这似乎是合适的（用户响应时间为8秒）。响应时间为38032毫秒（太长时间，因此调查），并于14：27：11.032结束。
在14:26:46，收到了/Action.aspx的POST。在上一个响应完成之前之前的8.2秒。是的，我完全清楚用户在点击链接以获取下一页或按下刷新之前不必总是等待页面完全呈现，但这种情况会发生很多，即使对于更短的请求也是如此。响应时间为124毫秒，完成时间为14：26：46.124。

在14:27:39，收到了/Information.aspx的GET。在前一个响应完成后的52.9秒。这似乎有点长，因为测试人员被告知要尽可能地打击系统，但这并不是很长。响应时间为52509毫秒（几乎正好是52.9秒！），结束时间为14：28：31.509。 如果我将时间字段解释为＆＃34;请求已收到，则发生 经常 的非常奇怪的巧合。＆＃34;

在14:27:52，收到了/Information.aspx的POST。在之前的响应完成之前之前的39.5秒。

这种模式在日志中一遍又一遍地持续着。

相反，如果我要解释＆＃34;时间＆＃34;字段表示＆＃34;响应完成＆＃34;，然后我得到更健全的数字：

大约14:25:16.236（14:25:17前764ms），收到了/Main.aspx的GET，需要764ms才能完成，在14:25:17完成响应。

大约14:25:25.891，收到了/Main.aspx的POST。在上一个响应完成后大约8.9秒。花了109ms来完成这个响应，在14:25:26结束。

大约14:25:27.218，收到了/_Start.aspx的GET。在上一个响应完成后的1.2秒。对于用户响应而言，这是快速的，但对于这些训练有素的测试人员来说，通过众所周知的菜单进行操作并不会太多。响应时间为28,782ms（太长，但这是性能分析的原因），并于14:25:56结束。

大约14：25：54.968，收到了/Action.aspx的GET。在上一个响应完成之前>大约1.0秒。这可能是舍入误差，因为时间字段不会捕获毫秒。响应时间为38032毫秒，于14:26:33结束。

大约14：26：45.876，收到了/Action.aspx的POST。在前一个响应完成后大约12.9秒。这对于用户响应时间来说非常正常。响应时间为124毫秒，于14:26:46结束。

大约14：26：46.491，收到了/Information.aspx的GET。这是在前一个响应完成后约0.5秒。这可能是脚本启动的重定向或快速用户。响应时间为52509毫秒，于14:27:39结束。慢页。

大约14：27：51.860，收到了/Information.aspx的POST。这是在上一个响应完成后大约12.9秒。正常的用户响应时间（巧合地与之前的POST相同）。响应耗时140毫秒，于14:27:52结束。

另一个原因是，对我来说，＃34; time＆＃34; field表示响应的结束，而不是请求的开头是这样的：

日志条目按照＆＃34; time＆＃34;的升序进行物理记录。字段（按时间顺序排列），但它们总是包含＆＃34; time-taken＆＃34;字段，只有在响应最终传递后才能知道。

那是哪条路？文档错了吗？

Answer 1

在此页面上：http://blogs.msdn.com/b/mike/archive/2008/11/13/time-vs-time-taken-fields-in-iis-logging.aspx

它说：

时间字段非常简单：它指定何时创建日志条目。请注意，这并不总是与日志条目实际写入日志时相同，因为某些请求/响应方案可能会发生缓冲。

因此，您认为时间与请求完成的时间最为接近是正确的。同一页继续澄清：

如果您想计算请求的大致开始时间，您可以从时间值中减去Time-Taken值。

日志中的“时间”字段到底表示什么？

1 个答案: