IIS）のASP.netアプリケーション用の個別のアプリケーションプール
Win2008サーバー上のasp.netアプリケーションごとに個別のアプリケーションプールを作成する必要があるという推奨事項を読みました。
同じサーバー上に約20個のアプリがあります。これにより、20の個別のワーカープロセスが作成され、非常に無駄に思えます。
アプリケーションごとに個別のアプリケーションプールを作成することをお勧めしますか？
ServerFaultから再投稿、 " IISにアプリケーションプールを追加する理由 "
- AppPoolsは異なるIDとして実行できるため、この方法でアクセス許可を制限できます。
- 各アプリプールに異なるIDを割り当てることができるため、タスクマネージャーを実行するときに、どのw3wp.exeがどれであるかがわかります。
- 異なるアプリプールで実行されているサイトに影響を与えることなく、1つのアプリプールをリサイクル/再起動できます。
- メモリリークがある、または一般的に誤動作するWebサイトがある場合は、他のWebサイトに影響を与えないようにアプリプールに配置できます。
- CPUを大量に消費するWebサイト（写真のサイズ変更など）がある場合は、それを独自のアプリプールに配置して、CPU使用率を抑えることができます。
- それぞれが独自のSQLデータベースを持つ複数のWebサイトがある場合は、web.configにユーザー名/パスワードを保存する代わりにActiveDirectory認証を使用できます。
理由がある場合は、アプリをプールで分離することをお勧めします。上記の理由はいくつかあります。ただし、アプリを異なるプールに分割しないのには十分な理由があります。
同じアクセス、.NETバージョンなどを使用するアプリは、単一のプールでより効率的に実行され、より簡単に保守できます。最も厄介なことに、IISはアイドル状態のアプリプールを強制終了し、使用するたびにプールを再作成する必要があります。使用頻度の低いアプリを分離すると、ユーザーに不要な起動コストがかかります。これらのアプリを組み合わせて単一のプールは、起動コストを支払わない場合はユーザーを幸せにし、複数のプロセスとCPUスライスにメモリを提供しない場合はサーバーを幸せにし、管理者が少ないアプリプールを管理する必要がある場合は管理者を幸せにします。
以前は、同じIIS7.5サーバー上に58の.NetWebサイトと17の古いクラシックASP Webサイトがあり、サイトごとに個別のアプリプールを使用していました。 IIS圧縮が断続的に失敗し始め、スタイルシートが約5％の確率で破損していることに気づきました。サーバー上のタスクマネージャーを見ると、サーバーが4GBのRAM制限に近づいていることがわかりました。各w3wp.exeプロセスは、サイトが取得しているトラフィックの量に応じて、最大100MBのメモリを使用していました。次に、すべてのWebサイトを2つのアプリケーションプール（1つは.net 4 Webサイト用、もう1つは古いクラシックASPサイト用）に移動しました。その後に使用されるメモリの合計は3.8GBから2.8GB弱に減少しました。 -サーバーの1GB以上のメモリスペースを節約できます。変更後（そしてサーバーを数時間実行して通常のレベルのトラフィックに戻す）、w3wpプロセスはすべての.net WebサイトWebサイトに300MB、従来のASPWebサイトに20MBを使用していました。 。 IIS圧縮を問題なく再度有効にすることができました。
上記の他の投稿で述べた多くの理由から、個別のAPPプールを使用することは素晴らしいアイデアですが、同じサーバー上でかなりの数のWebサイトをホストしている場合、私の経験では、メモリのオーバーヘッドがはるかに高くなります。
個別のアプリプールを使用するかどうかは、ハードウェアの制限とセキュリティの間のトレードオフだと思います。あなたがそれをするためのリソースを持っているならば、それは良い考えです。
はい、20のアプリケーションでも良い考えです。
- セキュリティ。さまざまなアカウントで実行されているさまざまなアプリプール。
- 隔離。 1つのクラッシュしたアプリが他のアプリを停止することはありません。
- メモリ（32ビットを実行している場合）。各アプリプールには、独自のアドレススペースがあります。したがって、1つのプロセスで最大約2.7GBの使用可能スペースよりもはるかに多くのメモリをアドレス指定できます。
- 他のアプリケーションに影響を与えることなく、動作が悪いアプリを定期的に再起動することを選択できます。
アプリが安定していてメモリをあまり使用しない場合は、同じアプリプールに配置しても問題ありません。アプリプールを使用すると、アプリケーションを分離できます。
アプリプールを作成するときに私が考慮する主な理由の1つは、プロセス管理です。セキュリティなどの他の理由があります。IISでホストされているアプリケーションがクラッシュすると、ホストプロセスも停止します。以前のバージョンのIISでは、これはすべてのWebアクティビティが一緒にクラッシュすることを意味していました。アプリプールを使用すると、アプリケーションを相互に分離できます。メモリリークが発生し、クラッシュし続ける場合、他のアプリは引き続き機能します。 。
異なるアプリケーションプールを作成する主な利点は、各プールに他の資格情報を提供できることです。 20個のアプリケーションは、すべて別のログインが必要な20個の異なるデータベースと通信する場合があります。その場合のベストプラクティスは、異なるサービスアカウントを使用して各アプリケーションを実行することです。
パフォーマンスについてはあまり心配しません。ほとんどの時間は、各アプリケーションがどのプロセスにあるかに関係なく、おそらく各Webアプリケーション内で費やされます。
これは、実際には、アプリケーション、セキュリティモデル、およびアプリケーションをどれだけ信頼しているかによって異なります。
アプリケーションプールを操作するときに常に考慮するように指示することがいくつかあります。
- 各アプリケーションがシステムリソースへの異なるアクセスを必要とする場合は、個別のアプリケーションプールを使用してください。 （複数のプロセスアカウントを使用できます）
- アプリケーションがリソースを大量に消費する、ミッションクリティカルな、または「不明」である場合は、アプリケーションを独自のプールに入れて、システムの他の部分から分離するのが最善です。
私たちは大企業のクライアントの外部請負業者として働いています。私たちはオンサイトではないため、すべてのシステムに接続できるわけではありません。開発中に、開発サーバーでアプリケーションを直接デバッグする必要がある場合があります。そのためには、w3wpプロセスにアタッチできる必要があります。アタッチしてデバッグを開始すると、プロセス全体が停止し、同じプロセス/アプリケーションプールにあるすべてのアプリケーションに影響します。専用のアプリケーションプールを作成し、そこに開発を移動することで、誰の人生も悲惨なものにすることなく、簡単にデバッグできます。