web-dev-qa-db-ja.com

ログの「時間」フィールドは正確に何を示していますか？

パフォーマンスの問題があるサーバーで、しばらくの間IIS 7.5のW3C形式のログファイルを調査してきましたが、 MSDNドキュメント とは逆のようです。 =、「時間」フィールドはnot

「協定世界時（UTC）での、要求が発生した時間」

...むしろ、応答の送信が終了した時刻です。

これは、ある程度制御された環境でユーザーからのページリクエストのシーケンスを追跡する場合、ユーザーは次のリクエストを送信するために時間を遡る必要があるためです。そうしないと、ユーザーはページのリクエストを驚くほど速く送信できます。時間がかかるエントリが多いページ。

たとえば（セキュリティと明確さのために、私は編集、省略、省略しています）：

#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

「time」を「requestreceived」（開始または終了、ただし応答が始まる前）と解釈すると、これは間違っているように見えます。これが私が意味することです：

  • 22：25：17に、/ Main.aspxのGETが受信され、応答の配信に764ミリ秒かかりました。つまり、応答は14：25：17.764まで終了しませんでした。
  • 14:25:26に、POST for /Main.aspxを受信しました。前の応答が終了してから8秒です。この応答を配信するのに109ミリ秒かかり、14：25：26.109に終了しました。 。
  • 14:25:56に、/ _ St​​art.aspxのGETが受信されました。これは、前の応答が終了してからほぼ30秒後です。これは適切なようです。ユーザーは、_Start.aspxへのリンクをクリックする前にMain.aspxを学習した可能性があります。奇妙なことに、この302リダイレクト応答（28782ms）を配信するのに29秒近くかかり、14：26：24.782に終了しました。しかし、それが理由を見つけるために私がログを見ている理由です。
  • 14:26:33に、/ Action.aspxのGETが受信されました。これは、前の応答が終了してから約8秒後です。それは適切と思われます（8秒のユーザー応答時間）。応答には38032ms（長すぎるため調査）かかり、14：27：11.032に終了しました。
  • 14:26:46に、POST for/Action.aspxを受信しました。8.2秒ですbefore前の応答が終了しました。はい、ユーザーがリンクをクリックして次のページを取得したり、[更新]を押したりする前に、ページが完全にレンダリングされるのを常に待つ必要はありませんが、リクエストがはるかに短い場合でも、これは頻繁に発生します。応答には124ミリ秒かかり、14：26に終了しました。 ：46.124。
  • 14:27:39に、/ Information.aspxのGETが受信されました。これは、前の応答が終了してから52.9秒です。テスターはシステムをできるだけ強く叩くように言われたので、それは少し長いように思えますが、それは不適切に長くはありません。応答には52509ms（ほぼ正確に52.9秒！）かかり、14：28：31.509に終了しました。 それは非常に奇妙な偶然の一致です非常に頻繁に私が解釈すると「リクエストを受信しました」としての時間フィールド。
  • 14:27:52に、POST for/Information.aspxを受信しました。これは39.5秒ですbefore前の応答が終了しました。

この種のパターンは、ログで何度も繰り返されます。

逆に、「時間」フィールドを「応答が終了した」という意味に解釈すると、次のようになります。

  • 14：25：16.236（14:25:17の前の764ms）に、/ Main.aspxのGETが受信され、配信に764msかかり、14：25：17に応答が終了しました。
  • 14：25：25.891頃、/ Main.aspxのPOSTを受信しました。前の応答が終了してから約8.9秒です。この応答を配信するのに109ミリ秒かかり、14：25に終了しました。 ：26。
  • 14：25：27.218頃、/ _ St​​art.aspxのGETを受信しました。これは、前の応答が終了してから1.2秒後です。これはユーザーの応答には高速ですが、よく知られたメニューをナビゲートするこれらの十分に訓練されたテスターに​​とってはそれほど多くはありません。応答には28,782ms（長すぎますが、これがパフォーマンス分析の原因です）かかり、14：25：56に終了しました。
  • 14：25：54.968頃、/ Action.aspxのGETが受信されました。これは約1.0秒です前前の応答が終了しました。時間フィールドはミリ秒をキャプチャしないため、これは丸め誤差である可能性があります。応答には38032msかかり、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に終了しました。

「時間」フィールドが要求の開始ではなく応答の終了を表すことが私にとってより理にかなっているもう1つの理由は、次のとおりです。

ログエントリは、「時間」フィールドの昇順（時系列）で物理的に記録されますが、常に「所要時間」フィールドが含まれます。これは、後でしか知ることができませんでした。応答は最終的に配信されました。

それで、それはどちらの方法ですか？ドキュメントは間違っていますか？

iisloggingiis-7.5w3c
25
Alan McBee - MSFT

このページ： http://blogs.msdn.com/b/mike/archive/2008/11/13/time-vs-time-taken-fields-in-iis-logging.aspx

それは言う：

時間フィールドは非常に単純です。ログエントリがいつ作成されたかを指定します。一部の要求/応答シナリオではバッファリングが発生する可能性があるため、これはログエントリが実際にログに書き込まれるときと常に同じであるとは限らないことに注意してください。

したがって、この時間はリクエストが終了した時間に最も近いと考えるのは正しいことです。その同じページは明確にするために続きます：

リクエストのおおよその開始時間を計算する場合は、Time値からTime-Taken値を減算します。

21
Wesley Smith