Web アプリケーションを 1 つの既定のアプリケーション プールに保持することよりも、専用のアプリケーション プールを持つことの長所と短所は何ですか?
5 に答える
長所:
- アプリケーションは互いに分離されています。IIS がそれに対応しない限り、アプリケーション プールのロックはそのプール内のアプリケーションのみを取り出します。
- 異なる ASP.NET ランタイムでアプリケーションを実行する機能 (必要に応じて 1.1 用のプールと 2.0 用の別のプール)
- 多かれ少なかれ重要なアプリケーションに対して異なるアプリ プール設定を持つ機能。たとえば、ASP.NET の企業 Web サイトでは、応答が重要であるためアンロードを防ぐために、非アクティブ状態が __ 分間続いた後にシャットダウンする必要がある場合があります。他のサイトでは必要ない場合があります。
- ファイル アクセスに関してプールを相互に保護できます。非常に制限されたユーザー アカウントで実行できるため、サード パーティや信頼できないアプリケーションに最適です。
短所:
- 各アプリケーション プールには独自のメモリ バンクと独自のプロセスがあるため、より多くのリソースを使用できます
- 複数のプロセスがあるため、アプリケーションのデバッグが難しいと感じる人もいます
アプリ プールでサイトを結合する主な理由は、メモリを節約することです。複数の w3wp.exe プロセスを実行すると、大きなメモリ オーバーヘッドが発生します。それらを分割する特別な理由がない場合は、それらをまとめておくことをお勧めします。
通常、専用のアプリ プールを使用すると、1 つのサイトで発生した問題が他のサイトに影響を与えることがなくなります。サイト間でアプリ プールを共有する場合、特定のサイト (またはアプリ プール) のみにエラー状態が存在する場合、ボックス上のすべてのサイトをダウンさせることができます。
また、同じ Web サーバー上で ASP.Net のバージョンを混在させる場合は、少なくとも ASP.Net バージョンごと、または Web サイトごとに異なるアプリ プールが必要になります。
アプリ プールを分離しない正当な理由は思いつきません。分離するのはとても簡単です。
私はジェイソンに同意します。
また、異なるアプリ プールに異なるユーザー (Windows アカウントなど) を指定することもできます。これにより、データベースで異なる権限を持つユーザーを設定できます。これにより、セキュリティが強化され、どの Web サイト/ユーザーがデータベースにアクセスしているかを追跡できるようになり、データベースのパフォーマンスの問題を追跡するときに役立ちます。
個別のアプリプールがある場合は、最初にサイトにアクセスし、リサイクル後にアプリプールをスピンアップする最初のユーザーの初期ロード時間にペナルティを支払います。
たとえば、一晩中誰もあなたのサーバーにアクセスしなかったとしましょう。IIS はスピンダウンします (デフォルトでは 20 分だと思います)。最初にサーバーにアクセスした人は、アプリケーションがメモリにロードされるまで遅延が発生します。
サイトの展開方法 (リリース モードなど) によっては、これが問題にならない場合もあれば、煩わしい場合もあります。
これが、サイトごとに 1 つではなく、単一の apppool/server への移行を検討している理由です。