web-dev-qa-db-ja.com

IIS7のDefaultAppPoolとClassic .NET AppPoolの違いは何ですか？

IISのタイムアウトに問題があります。 web.configでは、セッションタイムアウトは60分に設定されていましたが、20分後にセッションが終了しました。

この問題はIIS7でのみ発生し、IIS5では発生しません。

調査の結果、アプリケーションプールのタイムアウトが原因であることがわかりました。 App Poolが何もせずに20分間放置されると、IISはセッションを終了します。

アプリケーションがdefaultAppPoolを使用している場合、これは常に発生しますが、アプリケーションプールを従来の.NETアプリケーションプールに変更した場合、タイムアウトは発生しません。

どちらのモードにもアイドルタイムアウトがありますが、DefaultAppPoolではonlyが発生します。

  • どうしてこれなの？
  • Classic .NET AppPoolとDefaultAppPoolの違いは何ですか？
  • ClassicとIntegratedのパイプラインの違いは何ですか？
iisweb-applicationsiis-7application-pool
50
Alvaro

IIS7には、WCFをより適切にサポートするためのいくつかの大きな変更があり、重要な要素の1つは新しい統合アプリケーションプールです。 PDCからのこのセッションでは、WCFサービスのパフォーマンスを向上させる観点から、これらの課題のいくつかについて説明します。 http://channel9.msdn.com/pdc2008/TL38/

このページには、IIS7アーキテクチャの概要があります： http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/ 。次の2種類のアプリプールの目的に関するこの記事の重要な情報の一部を含めました。

統合アプリケーションプールモード

アプリケーションプールが統合モードの場合、IISおよびASP.NETの統合された要求処理アーキテクチャを利用できます。アプリケーションプールのワーカープロセスが要求を受け取ると、要求はイベントの順序付きリストを通過します。各イベントは、必要なネイティブおよびマネージモジュールを呼び出して、要求の一部を処理し、応答を生成します。統合モードでアプリケーションプールを実行することには、いくつかの利点があります。最初に、IISおよびASP.NETの要求処理モデルが統合プロセスモデルに統合されます。このモデルは、認証など、以前にIISおよびASP.NETで複製されたステップを排除します。さらに、統合モードでは、すべてのコンテンツタイプで管理機能を利用できます。

クラシックアプリケーションプールモード

アプリケーションプールがクラシックモードの場合、IIS 7.0はIIS 6.0ワーカープロセス分離モードのように要求を処理します。 ASP.NET要求は、最初にIISのネイティブ処理ステップを経てから、マネージランタイムでマネージコードを処理するためにAspnet_isapi.dllにルーティングされます。最後に、要求はIISを介してルーティングされ、応答を送信します。 IISとASP.NET要求処理モデルのこの分離により、認証や承認などのいくつかの処理ステップが重複します。さらに、フォーム認証などのマネージコード機能は、ASP.NETアプリケーション、またはaspnet_isapi.dllによって処理されるすべての要求をスクリプトにマップしたアプリケーションでのみ使用できます。実稼働環境をIIS 7.0にアップグレードし、統合モードでアプリケーションをアプリケーションプールに割り当てる前に、既存のアプリケーションの統合モードでの互換性を必ずテストしてください。アプリケーションが統合モードで動作しない場合にのみ、クラシックモードでアプリケーションをアプリケーションプールに追加する必要があります。たとえば、アプリケーションはIISからマネージランタイムに渡される認証トークンに依存している場合があり、IIS 7.0の新しいアーキテクチャにより、プロセスはアプリケーションを中断します。

57
Tim Clem

クラシックプールは、IISおよびISAPI。integratedは統合パイプラインを使用し、IISおよびASP.NET a（ 1つのプロセスのみを使用するIIS 7.0の改善された機能を活用します。各アプリケーションに新しいアプリケーションプールを作成し、アプリケーション要件に従って個別に構成することをお勧めします。

クラシックモードは次の手順に従います。

1.着信HTTP要求は、IISコアを介して受信されます。

2.要求はISAPIを介して処理されます。

3.リクエストはASP.NETを介して処理されます。

4.要求はISAPIを介して返されます。

5.リクエストは、HTTPレスポンスが最終的に配信されるIISコアを通過します

統合モード使用：

1.着信HTTP要求は、IISコアおよびASP.NETを介して受信されます。

2.適切なハンドラーがリクエストを実行し、HTTPレスポンスを配信します

に従ってweb.configのセッションタイムアウトを増やします

これを増やすと、アプリケーションがメモリなどのより多くのリソースを消費することになります

4
Stuart

あなたの質問には答えがあると思います。 IIS 6および7にはアプリケーションプールタイムアウトの概念があり、これはセッションタイムアウトとは異なります。

モードの違いは何ですか...すでに対処されています。パイプラインとモードの違いに関する質問が問題にどのように関係しているか、つまりタイムアウトについてはわかりません。

見通し：アイドルタイムアウトは、トラフィックのあるWebサイトでは発生しません。おそらく、QAサイトまたは開発ボックスでのみ発生する問題があります。アイドルタイムアウト設定は、多くの未使用のWebサイト（例：私のブログ）を持つ開発会社やホスティング会社の月5ドルでリソースを節約するために存在します。おそらく、パブリックサイトでのアイドルタイムアウトは望ましくありません。

セッションタイムアウト-Web設定で設定、ユーザーがサーバーにヒットしない場合、セッションタイムアウト。

Idle timeout20分間誰もWebサーバーに触れないので、リソースを節約するためにシャットダウンします。 IIS 6 では、これはアプリプールのパフォーマンスタブにあり、簡単に無効にできます。 IIS 7では、アプリケーションプールの詳細設定または processModel要素 で設定できます。 IIS 7をIIS 6ほど実行しませんが、web.configから要素を削除するか、0に設定すると、アイドルタイムアウトが無限になります。

2
Precipitous

DefaultAppPoolはweb.configのセッションタイムアウトの設定を無視しますが、ASPNet App Poolはweb.configの設定を使用します。

0
Jeff