Asp.net

IISのASP.netアプリケーション用の個別のアプリケーションプール



Separate Application Pools



解決：

ServerFaultから再投稿されました。「IISにアプリケーションプールを追加する理由」

  • AppPoolsは異なるIDとして実行できるため、この方法で権限を制限できます。
  • 各アプリプールに異なるIDを割り当てることができるため、タスクマネージャーを実行するときに、どのw3wp.exeがどれであるかがわかります。
  • 異なるアプリプールで実行されているサイトに影響を与えることなく、1つのアプリプールをリサイクル/再起動できます。
  • メモリリークがある、または一般的に誤動作するWebサイトがある場合は、他のWebサイトに影響を与えないようにアプリプールに配置できます。
  • CPUを大量に消費するWebサイト（写真のサイズ変更など）がある場合は、それを独自のアプリプールに配置して、CPU使用率を抑えることができます。
  • それぞれが独自のSQLデータベースを持つ複数のWebサイトがある場合は、web.configにユーザー名/パスワードを保存する代わりに、ActiveDirectory認証を使用できます。

理由がある場合は、アプリをプールで分離することをお勧めします。上記の理由はいくつかあります。ただし、アプリを異なるプールに分割しないのには十分な理由があります。



同じアクセス、.NETバージョンなどを使用するアプリは、単一のプールでより効率的に実行され、より簡単に保守できます。最も厄介なことに、IISはアイドル状態のアプリプールを強制終了し、使用するたびにプールを再作成する必要があります。使用頻度の低いアプリを分離すると、ユーザーに不要な起動コストがかかります。これらのアプリを1つのプールに組み合わせると、起動コストを支払わない場合はユーザーが幸せになり、複数のプロセスとCPUスライスにメモリを割り当てない場合はサーバーが幸せになり、管理するアプリの数が少ない場合は管理者が幸せになります。プール。


以前は、同じIIS7.5サーバー上に58の.NetWebサイトと17の古いクラシックASPWebサイトがあり、サイトごとに別々のアプリプールを使用していました。 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サイトをホストしている場合、私の経験でもはるかに高いメモリオーバーヘッドが発生します。

個別のアプリプールを使用するかどうかは、ハードウェアの制限とセキュリティの間のトレードオフだと思います。あなたがそれをするためのリソースを持っているならば、それは良い考えです。