ASP.NETアプリケーションのタイミング初期起動

Question

iisresetまたはアプリケーションドメインのリサイクル後にASP.NETアプリケーションが最初のページ要求を読み込むのに時間がかかります。

アプリドメインのリサイクルにかかる時間を確実に測定する方法はありますか？

Answer 1

プロセスを監視してCPU時間がゼロになるのを待っているアプリケーションを書くのは、ストップウォッチを使用して何度か再起動する必要がある可能性が最も高いアプリケーションです。何秒ものタイミングになると、ミリ秒はそれ以上重要ではありません。だから、ストップウォッチは十分なはずです。

Answer 2

プロファイラを使用して、さまざまなCPUサンプリングモードのボトルネックを測定してコードをナビゲートすることができます。そのようなツールはdotTraceです。 :) http://www.jetbrains.com/profiler/

Answer 3

私たちも同様の問題がありました。私たちの経験が役立つかどうかはわかりません。幸いにも、これはサービス指向アーキテクチャーを最初に調査していたときに起こったので、データを取得する他の方法と比較してWebサービスを使用してパフォーマンスにどのような影響を与えるかに非常に関心がありました。

私たちの結果はがあなたに参考になると言ってますが、おそらく方法論ていませんよ。

異なる接続シナリオをテストするだけで何もしませんでしたが、実際にバイナリデータではなくXMLを使用してデータを取得することに関連した追加帯域幅について特に興味がありました。 XMLデータを取得するだけでは、パフォーマンスの低下が完全に予想されました。これは、ネットワーク全体でバイト数が増えると想定していました。

それ自体は10ページのドキュメントなので、私は結果には出ませんが、アクセスしていた.Net言語で書かれたWebサービスからデータを取得したときに発生した面白いラグを見つけましたiSeries（AS/400、System i、またはこれらの新しい用語が何であっても）のデータ。あなたと同じように、データを取得するための最初の呼び出しには時間がかかりましたが、それ以降の呼び出しは速くなりました。

私たちが使用していた接続の種類（Microsoftから提供されたODBC）は、このケースではネットワークパケットを調べることで犯人となりました。

クライアントとWebサービスの間、およびWebサービスとiSeries（データストア）間のネットワークパケットを測定したところ、Webサービスが最初にWebサービスといくつかの不要なパケットが前後に送信されていました。

簡単に言えば、Windows側は接続要求を送信し、数ミリ秒待ってから別のものを送信します。一方で、iSeriesは応答が遅かったので、最初の接続では、Windows側からiSeries側に接続するための呼び出しが4回、iSeriesからの応答が4回ありました。接続のWindows側はあきらめていた）。最後に4〜6回の試行の後、接続が確立されました。その後、短時間で後続の接続が迅速だったため、接続がプールされている必要があります。しかし、時間が経過すると（これが起こるためにどれくらいの時間が必要かを決めることはできませんでした）、ゆっくりとした初期接続が再現されました。

そんなに長い間、@Aggelos Mpimpoudisはあなた自身のコードのプロファイリングを提案していました。私の提案は、ネットワークパケットを分析し、プロセス全体を分析するための経験とツールを持っている人を見つけることです。あなたはそのように犯人を追跡することができるかもしれません。

ちなみに、System.Data.Odbcドライバの代わりにIbm.Data.Db2.iseriesを使用してiSeriesに接続した後、私たちの問題は改善されました。 iSeriesはプールされた接続をオープンに保つのに十分でした。