IIS のタイムアウトに問題があります。web.config では、セッション タイムアウトは 60 分に設定されていましたが、20 分後にセッションが終了します。
この問題は IIS7 でのみ発生し、IIS5 では発生しません。
調査の結果、アプリケーション プールのタイムアウトが原因であることがわかりました。アプリケーション プールが何もせずに 20 分間放置されると、IIS はセッションを終了します。
アプリケーションが defaultAppPool を使用している場合、これは常に発生しますが、アプリケーション プールを従来の .NET アプリケーション プールに変更すると、タイムアウトは発生しません。
どちらのモードにもアイドル タイムアウトがありますが、これが発生するのは DefaultAppPoolだけです。
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 の新しいアーキテクチャが原因で、そのプロセスによってアプリケーションが機能しなくなることがあります。
クラシック プールは、IIS と ISAPI の個別の処理パイプラインを使用して、アプリ プール内の要求を処理します。統合は統合されたパイプラインを使用し、IIS と ASP.NET の (より優れたパフォーマンス) は、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 のセッション タイムアウトを増やします。
これを増やすと、アプリケーションがより多くのリソース (メモリなど) を消費することを覚えておいてください。
あなたの質問には答えがあると思います。IIS 6 および 7 にはアプリケーション プール タイムアウトの概念があり、これはセッション タイムアウトとは異なります。
モードの違いは何ですか...すでに対処されています。パイプラインとモードの違いに関する質問が、タイムアウトという問題にどのように関係しているかはわかりません。
いくつかの観点: アイドル タイムアウトは、トラフィックのある Web サイトでは発生しません。QA サイトまたは開発ボックスでのみ発生する問題が発生している可能性があります。アイドル タイムアウト設定は、開発ボックスのリソースを節約するために存在し、使用されていない Web サイト (私のブログなど) が多い月額 5 ドルのホスティング会社を節約します。パブリック サイトではアイドル タイムアウトは望ましくないでしょう。
セッション タイムアウト- Web 構成で設定します。ユーザーがサーバーにアクセスしない場合、セッションがタイムアウトします。
アイドル タイムアウト20 分間、誰も Web サーバーにまったくアクセスしないため、リソースを節約するためにシャットダウンします。IIS 6では、これはアプリケーション プールの [パフォーマンス] タブにあり、簡単に無効にできます。IIS 7 では、アプリケーション プールの詳細設定またはprocessModel 要素で設定できます。IIS 6 ほど IIS 7 を実行していませんが、web.config から要素を削除するか、0 に設定すると、無限のアイドル タイムアウトが発生するようです。
DefaultAppPool は web.config のセッション タイムアウトの設定を無視しますが、ASPNet アプリケーション プールは web.config の設定を使用します。