私は最近 WCF サービスを技術的にテストしており、理解が不足しているため、先に進んでタイムアウトの問題の解決策を見つけることができないところまで来ました。
Windows Server 2008 の IIS7 でホストされている WCF サービスの負荷テストを行っています。メッセージを起動するように設定されたシステムは、実際には、biztalk であるアプリケーションでメッセージを起動します。次に、Biztalk はメッセージを処理し、WCF サービスのエンド ポイントに送信します。WCF サービスもアプリ プールで .net 2.0 を使用しています (これは、完全なリリースではないため、実際には 3.0 または 3.5 である可能性があることを意味すると思いますか?
1 秒以内に 40 件のメッセージを送信し、クライアント (biztalk) での送信タイムアウトが原因で、それらの 90% がタイムアウトになります。サーバーの基本的な http バインディングの受信タイムアウトが最初にトリガーされると予想していたため、最初はこれは奇妙だと思いましたが、10 分に設定され、クライアントの送信タイムアウトが 1 分 30 秒に設定されていることが判明しました。
私が理解していること:
WCF サービスには、動作と http バインディングを内部に持つ構成ファイルがあります。XML メッセージを送信するサーバー エンドポイントは、BasicHtppBindings を使用しています。タイムアウト: オープン/クローズは 1 分、送信と受信は 10 分です。これまでのところ関与していることがわかっているサーバーのタイムアウトは、sendtimeout: 1 分です。
WCF のアーキテクチャは、チャネル ファクトリまたはサービス ホストのいずれかのインスタンスを作成することによって機能し、構成からの動作とバインディング設定をチャネルとして含むチャネル スタックを作成することを理解しています。チャネル スタックを介して処理された xml メッセージを移動するために使用される TransportAdaptor があります。
http.sys が着信要求を処理することを IIS から理解しています。要求をワーカー プロセスに渡し、それがビジー状態になると、要求をカーネル モード キューに配置しますか? このキューを増やしたり、このキューを制限したりするために設定できる machine.config 設定がいくつかあることを理解していますか?
また、アプリケーション プールを Webgarden にする方法についても知っており、コアあたりのスレッド数をデフォルトの 12 から増やすことができることを読みました。これは、レジストリ設定を介して行うか、後で .net で Web 構成を変更します。
InstanceContextMode と、それがサーバーのサービスにもどのように影響するかについて読んだところですが、この場合、それが何に設定されているかわかりません。
いくつかのパフォーマンス カウンター (.net カウンター) を記録したところ、現在の要求数から (Queued + Disconnected) = 12 を引いた数に気付きました。これは、1 つのコアを使用していることを示していますか? そのコアのスレッド数は 12 に設定されています。
より明確な全体像を得るために誰かが私を助け、私の知識をより完全なものに追加するのを助けることができますか?