誰もが知っているように、24 時間 365 日稼働するアプリケーションを実装するのは簡単ではありません。私のプロジェクトの 1 つは、かつて激しい負荷の下で 20 時間以上持続しましたが、それでも英雄的に終了しました。幸いなことに、ASP.NET と IIS は、非常に安定した .Net アプリケーションを簡単に構築できるいくつかの簡単な機能を提供します。ただし、少し不快なのは、Windows 2000 (IIS6.0 より前のバージョン) と Windows 2003 (IIS6.0) システムでの構成方法が異なることです。
まず Windows 2000 システムについて説明します。ASP.NET に詳しい人は、%WindowPath%Microsoft.NetFramework%.NetVersion%CONFIG ディレクトリに保存されている machine.config ファイルを知っているはずです。任意のテキスト エディタ (もちろん、最も一般的なのは「メモ帳」) を使用してファイルを開き、<processModel...> セクションを見つけます。 ASP.NET は、このセクションの設定に基づいて ASP.NET サービス プロセス (aspnet_wp.exe または w3wp.ext) を制御します。私たちが作成した ASP.NET アプリケーション コードは、このプロセス空間で実行されます。 Framework 1.1 を使用している場合、このセクションには n 個以上のプロパティが表示されます。次の 3 つが関係しており、その後に等号が付いているのはそれらのデフォルト値です。
timeout="Infinite"
idleTimeout="Infinite"
memoryLimit="60"
Framework 2.0 ではこれらは表示されませんが、手動で追加できます。
これら 3 つの属性の意味を説明します。タイムアウトで指定された時間継続して実行した後、ASP.NET サービス プロセスを再起動します。タイムアウトのデフォルト値は「HH:MM:SS」の形式でリセットできます。 " 、たとえば、 timeout=24:00:00 は 24 時間後に再起動することを意味します。 idleTimeout で指定された時間内に誰もアクセスしなかった場合、ASP.NET サービス プロセスを再起動します。 idleTimeout のデフォルト値も無限であり、設定方法は上記と同じです。システム メモリ全体に対する ASP.NET サービス プロセスによって使用されるメモリの割合が、memoryLimit で指定された量を超えると、ASP.NET サービス プロセスが再起動されます。
これら 3 つの属性の連携により、サービス プロセスが知らず知らずのうちに再起動され、アプリケーションが実行を継続できることを理解してください。これを言うと、注意深い読者は問題に気づいたかもしれませんが、サービス プロセスが再起動されると、クライアントのセッションが必然的に失われ、ユーザーの操作が中断されます。どうしたら「神も知らず、幽霊も知らない」を実現できるのでしょうか？
この問題は確かに存在しますが、次の方法でその影響を最小限に抑えるか、完全に排除することができます。
まず、idleTimeout を適切な値に設定します。通常は、セッション タイムアウト設定の 1.5 ～ 1.5 に設定します。タイムアウトをプログラムが持続できる上限に設定します。通常は 24 時間に設定します。これにより、アイドル状態のサービス プロセスが強制的に再起動されます。この時点ではセッションがないため、ユーザーの操作を中断することはできません。基本的に時間外のアクセスがない中小企業のオフィス環境では、この設定は非常に有効です。
もちろん、上記の方法には大きな制限があり、特定の状況でのみ機能します。メモリが制限を超えた状態で誰かがアクセスを続けたり、再起動したりしても、ユーザーの操作は妨げられます。究極の解決策は、セッション状態を別のプロセスに保存することです。 ASP.Net では、これも簡単な構成で可能です。
出典：BLOG記録室