IIS 7.xアプリケーションプールのベストプラクティス

いくつかの新しいサーバーに多数のサイトを展開しようとしています。アプリケーションプールについて次の質問があります。

Webサイトごとに1つのアプリケーションプールを用意することをお勧めします。このアプローチには注意点がありますか？1つのアプリケーションプールがすべてのCPU、メモリなどを占有しますか？
アプリケーションプールで複数のワーカープロセスを許可するタイミングいつすべきではないのですか？
あるアプリケーションプールが別のアプリケーションプールに干渉するのを防ぐために、プライベートメモリの制限を使用できますか？設定が低すぎると、有効な要求が有効な応答を取得せずにアプリケーションプールをリサイクルすることになりますか？
プライベートメモリ制限と仮想メモリ制限の違いは何ですか？
サイトごとに1つのアプリケーションプールを実行しない理由はありますか？

— エリック・バーチャム
ソース

最初の質問：これらのWebサイト（例：.htm / .js）、またはWebアプリケーション（例、.aspx / .php）ですか？

— コーディングゴリラ

主に.Net 3.5アプリケーション。1つは、サードパーティのPHPアプリケーションです。

— エリックバーチャム

これは一種の幅広いトピックです-主題（および@CodingGorillaの回答）は興味深いものですが、SFのQ＆Aスタイルには最適ではないかもしれません

— -voretaq7

回答:

1）Webサイトごとにアプリケーションプールを用意することをお勧めします。このアプローチには注意点がありますか？たとえば、1つのアプリケーションプールですべてのCPU、メモリなどを占有できますか？

これはかなり良いアプローチです。異なる「サイト」（アプリケーション）が同じプールを共有すると考えることができる理由はありません。ある種の単一のリソースを共有する必要がない限り。理論的には、1つのアプリケーションが大量のCPUまたはメモリを消費する可能性がありますが、アプリケーションのプール方法を変更しても、それほど大きな影響はありません。

2）アプリケーションプールで複数のワーカープロセスを許可するタイミング。いつすべきではないのですか？

これは、デフォルト設定を使用して、そのままにしておくのが最善です。あなたが何をしているのか本当に理解していない限り、これは実際にあなたのウェブサイト/アプリケーションに悪影響を及ぼす可能性があります。

3）プライベートメモリ制限を使用して、あるアプリケーションプールが別のアプリケーションプールに干渉するのを防ぐことができますか？設定が低すぎると、有効な要求が有効な応答を取得せずにアプリケーションプールをリサイクルすることになりますか？

a）理論的に

b）はい、低く設定するとマイナスの影響があります。繰り返しますが、特定のニーズがあり、何をしているのかわからない場合は、そのままにしておきます。

4）プライベートメモリ制限と仮想メモリ制限の違いは何ですか？

それは非常に複雑です、ここに私が見つけた簡単な投稿があります：http : //cybernetnews.com/cybernotes-windows-memory-usage-explained/

5）サイトごとに1つのアプリケーションプールを実行しないという説得力のある理由はありますか？

繰り返しになりますが、私が考えることができる唯一の理由は、複数のアプリケーションが必要とする何らかの「共有リソース」がある場合、同じプロセスでそれらを実行することです。

汎用アプリケーションとWebサイトの場合、IISはデフォルト値でかなり適切に設定されています。

****更新****

＃2の追加情報のリクエストに関しては、特にそうする必要がない限り、これを行うべきではありません。時間がかかるサーバーアクションであっても、要求は複数のスレッドを使用して処理されるため、「非同期要求」を使用して長時間実行されるタスクを処理します（スレッドプールスレッドを解放して他の要求を処理します）。現実的には、単一のプールに対して複数のプロセスを許可する正当な理由は考えられません。

複数のプロセスについて話し始めたら、プロセス1でセッションが生きているためにセッション状態を失うが、リクエストはプロセス2で処理されているなどの可能性があります。さらに悪いことに、方法を理解する必要がありますいくつかのプロセス間通信を行いますが、これは本当に苦痛です。

複数のプロセスの理由に関して何が来ても、（別のプロセスを起動するのではなく）それに対処するより良い方法があると確信しています。

— コーディングゴリラ
ソース

思慮深い答えに感謝し、それを受け入れました。＃2についてさらに具体的な情報があれば、感謝します。「ベスト・アフター・アローン」は確かに賢明なアドバイスですが、複数のワーカー・プロセスを使用する場合も知っておくとよいでしょう。これは、大きなレポート、大きな投稿を受け入れるWebサービスなど、応答を返すのに時間がかかるサーバーアクションがある場合に、より関連性があると思います。私はまた、すべての通常のスレッド並行性のものが適用されると思いますか？

— エリックバーチャム

追加するだけ：アプリの連携が不十分な場合、IISのインストールダイアログには、Windowsシステムリソースマネージャーをインストールして、アプリプールによるCPUとメモリの使用を制限できることが示されます。

— TristanK

@TristanK、ヒントをありがとう。それは非常に役に立ちました。

— エリックバーチャム

@Coding Gorilla-洞察力をありがとう。私は「なぜウェブガーデンを使うのか」を真剣に掘り下げることに決め、いくつかの回答を思いつきました。あなたが言及したすべての警告が適用されます。特に、さまざまなキャッシュやユーザーセッションなどの共有リソースへの非同期アクセスを処理します。Webガーデン機能を使用すると、基本的に、単一のサーバーにコア以上の負荷を分散させることができます。そのため、要求のルーティングを除き、負荷分散シナリオで通常対処するすべての警告に対処する必要があります。

— エリックバーチャム

@Coding Gorilla-続き...複数のワーカープロセス機能を使用することがわかった最高の「理由」は、パフォーマンスを向上させることです。このリンクをご覧ください：iis-aid.com/articles/performance_testing/…。もちろん、ほとんどの場合（少なくとも最初は）単一のワーカースレッドを実行するため、Webサイトの考慮に入れないことが多いプログラミングのすべての非同期の側面で何をしているのかをよく知っている必要があります。したがって、私の質問に対する簡単な答えは次のとおりです。パフォーマンスに問題がある場合は試してみてください。

— エリックバーチャム

私は常にWebサイト専用のアプリケーションプールを構成します。低コストのWebサイトホスティングシナリオは、アプリケーションプールごとに多数のサイトを持つことが理にかなっています。

メモリ制限は、サイトがすべてのシステムリソースを消費することを防ぐための、実際の原始的な安全しきい値にすぎません。これは、IIS 6.0 x86よりもWindows 2008 R2 x64の方が潜在的な問題であることに注意してください。x86アプリケーションには自然な2 GBのメモリ上限があったためです。IIS 7.5では、メモリリークのあるアプリケーションが大量のメモリを消費する方がはるかに簡単です。

また、アプリケーションプールのリサイクルの大ファンでもありません。アプリケーションプールがあり、実行している唯一のアプリケーションである場合、コードに問題がなければ、おそらくアプリケーションプールをリサイクルする必要はありません。そして、アプリケーションに欠陥がある場合、究極の適切なアクションはコードを修正することです。

— グレッグ・アスキュー
ソース

メモリの32ビットキャップを指摘していただきありがとうございます。私はこれらのことをどのように忘れるかわからない。また、アプリケーションプールがクラッシュするほど欠陥のあるアプリケーションがある場合の正しいアプローチは、コードにアクセスできると仮定して修正することだと思います。アドバイスに感謝します！

— エリックバーチャム

独自のテストを行いました。アプリケーションプールを実行すると、すべて同じアプリケーションプールでアプリケーションを実行するよりも、アプリケーションプールごとに約64Kのオーバーヘッドがあるようです。これは、パフォーマンスモニターを使用してメモリ消費を監視する12時間のサンプル期間です。これは64ビットサーバー上にありました。この単純なテストが正しいことが判明した場合、アプリケーションごとに1つのアプリプールのリソースコストは、最新のハードウェアでは基本的に無視できると思います。

— エリックバーチャム