IISのASP.netアプリケーション用のアプリケーションプールの分離

Question

Win2008サーバー上のasp.netアプリケーションごとに個別のアプリケーションプールを作成することをお勧めします。

私たちは同じサーバー上にある約20のアプリを持っています。私はこれが非常に無駄に思われる20の別々のワーカープロセスを作り出すことを知っています。

アプリケーションごとに個別のアプリケーションプールを作成することをお勧めしますか？

Answer 1

あなたが権限をこのように制限することができますので、 "Why add additional application pools in IIS?"

• アプリケーションプールは、など、さまざまなアイデンティティを実行することができます。
• タスクマネージャを実行すると、どのアプリケーションがどのw3wp.exeであるかを知ることができるように、各アプリケーションプールに異なるIDを割り当てることができます。
• 異なるアプリケーションプールで実行されているサイトに影響を与えずに、1つのアプリケーションプールをリサイクル/再起動できます。
• メモリリークや一般的に不正なウェブサイトがある場合は、他のWebサイトに影響を与えないようにアプリケーションプールに配置することができます。
• 非常にCPU集約型のウェブサイトたとえば、写真のサイズ変更のように）、自分のアプリケーションプールに配置してCPU使用率を調整することができます。
• それぞれに独自のSQLデータベースがあるWebサイトがある場合は、ユーザー名/パスワードweb.configで。

Answer 2

あなたのアプリが安定していて多くのメモリを使用していない場合は、同じアプリプールに入れても問題ありません。アプリケーションプールは、アプリケーション間の分離をもたらします。

Answer 3

私がアプリケーションプールを作成するときに考慮する1つの主な理由は、プロセス管理です。セキュリティなどの理由があります。 IISでホストされているアプリケーションがクラッシュすると、ホストプロセスも停止します。以前のバージョンのIISでは、これはすべてのWebアクティビティが同時にクラッシュすることを意味していました。アプリケーションプールを使用すると、アプリケーションを互いに分離することができます。メモリリークが発生してクラッシュすると、他のアプリは引き続き機能します。

Answer 4

異なるアプリケーションプールを作成する主な利点は、各プールに他の資格情報を提供できることです。 20のアプリケーションは、別のログインが必要な20の異なるデータベースと通信することができます。ベストプラクティスは、別のサービスアカウントを使用して各アプリケーションを実行することです。

私はパフォーマンスについてあまり心配しません。

Answer 5

これは実際にはアプリケーション、セキュリティモデル、およびアプリケーションの信頼度によって異なります。ほとんどの時間はおそらく各Webアプリケーションの内部で費やされます。

ここでは、アプリケーションプールを操作する際に常に考慮する必要があることをいくつか挙げておきます。

• 各アプリケーションがシステムリソースに異なるアクセスを必要とする場合は、個別のアプリケーションプールを使用します。
• アプリケーションがリソース豚、ミッションクリティカル、または "不明"の場合は、システムの残りの部分と分離するために、独自のプールに配置することをお勧めします。

Answer 6

はい、20のアプリケーションでも良いアイデアです。

1. セキュリティ。異なるアカウントで実行されている異なるアプリケーションプール。
2. アイソレーション。 1つのクラッシュするアプリは他のアプリを削除しません。
3. メモリ（32ビットを実行している場合）各アプリケーションプールは独自のアドレス空間を持ちます。したがって、1プロセスあたり最大約2.7GBの使用可能なスペースよりもはるかに多くのメモリを扱うことができます。
4. 他のアプリケーションに影響を与えることなく、動作の悪いアプリを定期的に再起動することを選択できます。 ServerFaultのから転載

Answer 7

プールでアプリを分けることは、理由があるときに行うのが良いことです。上に挙げた理由がいくつかあります。しかし、アプリを別々のプールに分けないことも良い理由があります。

同じアクセス、.NETバージョンなどを使用するアプリケーションは、1つのプールでより効率的に実行され、より簡単に管理されます。最も厄介なことに、IISはアイドル状態のアプリケーションプールを強制終了し、各使用時にプールを再作成する必要があります。頻繁に使用されていないアプリケーションを分離すると、ユーザーに不必要な起動コストがかかります。これらのアプリケーションを1つのプールにまとめると、スタートアップコストを支払わなければより幸せなユーザーになり、複数のプロセスやCPUスライスにメモリを与えないと幸せなサーバーになり、管理する管理者が少ないプール。

Answer 8

以前は、各サイトごとに別々のアプリケーションプールを使用して、58の.Net Webサイトと17の古いASP Webサイトを同じIIS7.5サーバーに配置しました。断続的にIIS圧縮が失敗し、スタイルシートが約5％壊れてしまったことに気付きました。サーバーのタスクマネージャーを見ると、サーバーが4GB RAM制限に近づいていたことがわかりました。各w3wp.exeプロセスは、サイトのトラフィック量に応じて最大100MBのメモリを使用していました。その後、すべてのWebサイトを2つのアプリケーションプールに移動しました（1つは.net 4 Webサイト用、もう1つは古い従来のASPサイト用）。これを実行した後に使用されるメモリの総量は3.8GBから2.8GBに減少しました。サーバー上のスペース。変更後（サーバーを通常のトラフィックレベルに戻すために数時間稼働させたままにしておく）、w3wpプロセスは.net WebサイトのすべてのWebサイトに対して300MBを使用し、従来のASP Webサイトに対しては20MBを使用していました。私は問題なくIIS圧縮を再び有効にできます。

別のAPPプールを使用することは、上記の他の投稿に記載されている多くの理由のための素晴らしいアイデアですが、同じサーバー上にかなりの数のWebサイトをホストしていると、

ハードウェアの制限とセキュリティの間には、別々のアプリケーションプールを使用するかどうかは関係ありません。それを行うためのリソースがあれば良い考えです。