アプリケーションのバックエンドのパフォーマンスを改善し、GUI のエンド ユーザーにメリットを示すために、Trace.axd ページを使用してタイミングを計っています。(フロントエンドは .Net 1.1、バックエンドは Java で、Web サービス経由で接続されています。)
ただし、これらのタイミングは、古いバックエンドと新しいバックエンドの間で違いはありません。
バックエンドにブレークポイントを設定し、そこでリクエストを 30 秒間保持すると、Trace.axd から、POST に 3 ミリ秒、GET に 4 秒かかっていることがわかります。26秒くらい抜けてる…
POST はパフォーマンスの向上が必要な場所ですが、Trace ページのタイミングには、要求を送信するのにかかる時間のみが含まれているようで、戻るのにかかる時間は含まれていないようです。
トレース内の情報の粒度を上げて、リクエスト全体を含める方法はありますか? または、必要な測定を行う別の方法はありますか?
OK、最終的に欲しいものを手に入れました。問題は、IIS トレースに、POST が戻るまでの時間が含まれていないことです。
Trace.Write() を使用してトレース ログにカスタム エントリを追加したり、Trace.Write(string category, string message) を使用してカテゴリを追加したりできることがわかりました。
POST の完了後に実行されるコードに Trace.Write() の呼び出しを追加すると、より正確な数値が得られます。
それでも、それはカスタムなので理想的ではありません.POSTサイクルの終わりにできるだけ近づけるのは私次第です.
ブレークポイントで費やした時間がトレース出力に表示されないのは異常です。合計時間列をチェックして、リクエストに費やした時間と一致するかどうかを確認しましたか? 列の 1 つは、前のトレース ステートメント以降に費やされた時間だけを示していることを忘れないでください。
トレース出力でより詳細なデータが必要な場合は、独自のデータを追加できます。TraceContext クラスには、出力に行を追加する Warn と Write の 2 つのメソッドがあります (warn は赤で追加します)。
TraceContext は、すべてのページまたはコントロールからアクセスできます。 this.Trace.Warn() または this.Trace.Write() を使用するだけです (HttpContext クラスからもアクセスできると思います)。
.NET 側でどのようにリクエストを行っているのかわかりませんが、どこかに HttpWebRequest が関係していると思います。応答ヘッダーを受信するとすぐに HttpWebRequest.GetResponse() が返されることを期待しています。そうすれば、残りがまだダウンロードされている間に、大きな応答の開始の処理を開始できます。したがって、トレース メッセージが GetResponse の呼び出しの直前と直後にある場合、バックエンドの実行時間全体が表示されません。応答を閉じた直後にトレース メッセージを追加できますか?