あなたがイベントやThreadPoolのスレッドが何をしているかを教えてくれるいくつかの種類の公共のフックを期待している場合は、残念ながらそのような事はありません。
私は役立つかもしれない他の二つのアプローチを考えることができます。
まず、あなたがworkerThreadsの値を確認することができます前に、あなたのライブラリーに呼び出した後、ThreadPool.GetAvailableThreads()
から生じます。値が変更されると、ライブラリが原因である可能性があります。これは、単一の要求のみを処理するテスト環境では意味がありそうです。また、カスタムWindowsパフォーマンスカウンタにworkerThreads番号を保存して、時間の経過と共に追跡することもできます。おそらく、これを使用して、一方のアプローチと他方のアプローチを比較することができます。
はここでパフォーマンスカウンタのアプローチを説明する記事へのリンクです:あなたはIIS 7+を使用している場合
http://msdn.microsoft.com/en-us/library/ff650682.aspx
、別の可能性は4.0+ .NETでHostingEnvironment
経由(MaxConcurrentRequestsPerCPU
を無効にすることで、または.NET 3.5以降のaspnet.configファイルを使用して)0に設定し、MaxConcurrentThreadsPerCPU
を比較的少数に設定して、ライブラリ内の1つのインターフェイスと別のインターフェイスを使用して負荷のかかったアプリケーションのパフォーマンスを測定します。十分なスレッドがないために要求がキューに入れられると、応答時間がそれに応じてジャンプします。これを行う方法の詳細と残念なことに測定値は、ライブラリとWebリクエストの構造に依存します。
"プール内のスレッドを呼び出すときと解放したときのあなたのプログラムの内部を知っていますか? - いいえ、私はしません!私のプログラムはサードパーティのライブラリを使用しているからです。 – thorn
@thornこのライブラリのデバッガが必要ですか?それはあなたの問題を作る特別な点ですか?あなたはここで何を解決しようとしていますか? – Aristos
私が望むのは、非同期メソッドを気にする必要があるかどうかを判断するために、サードパーティのライブラリの動作を調べることです。これらのメソッドが共通プールからスレッドをブロックする場合、それらのメソッドを使用してもASP.NETアプリケーションには何のメリットもありません。ライブラリは難読化されているので、私は逆コンパイラで答えを検索したくありません。 – thorn