新しいアプリをライブ環境に展開するプロセスが進行中です。
アプリケーション サーバーは、EntityFramework を使用し、非 .NET COM+ アプリケーションに対して多数の呼び出しを行う IIS ホスト .NET アプリケーションを実行しています。
IIS アプリケーション プール内の最大ワーカー プロセス数を変更することで、純粋な .NET コードのパフォーマンスに影響を与えることができましたが、ワーカー プロセスの数はコンポーネント サービスのアプリケーション プールのプール サイズとどのように関係するのかが疑問です。次のようなものがあります。
- これら 2 つの値の間に 1 対 1 の関係を目指すべきでしょうか?
- 複数のワーカースレッドを避けるべきでしょうか?
ご意見をいただければ幸いです。
答え1
2 つのプールのワーカー プロセスの数は直接関連していません。確立する必要があるのは、各プールの滞在時間です。したがって、IIS ワーカーがビジー状態であり、全体の時間のごく一部のみが COM アプリケーションに費やされる場合、COM スレッドがパフォーマンスのボトルネックになる可能性は低くなります。
ストレス状況でアクティブなスレッドの数を測定して、個々のプールのサイズを制御する方法を決定します。
IIS ワーカー プロセスは、プロセッサ使用率以外の基準でもリサイクルされることも考慮してください。これにより、呼び出し間でデータを共有する能力に重大な影響が及ぶ可能性があり、直接的なパフォーマンスに大きく影響する試みが台無しになる可能性があります。
単一の .NET クエリから複数のリクエストを集約できる薄い COM ラッパーを検討することで、.NET から COM へのブリッジングにかかるコストを削減する方がよいでしょう。これには、複数の COM メソッドをプールから単一のスレッドに統合するという副作用もあります。