シナリオ: Web展開プロジェクトを使用して展開されたn層エンタープライズASP.NETアプリケーションがあります。すべての層は、ASP.NETアプリケーションによって使用される独立したアセンブリを生成します。
問題:アプリを実行したとき。配置後初めて、依存アセンブリをメモリにロードするのに長い時間がかかります。しかし、その高速なアプリをロードしたら。アプリにアクセスしているユーザーがいない場合、IISはメモリからアセンブリをアンロードし、ユーザーが後のインスタンスでアプリにアクセスしようとすると、もう一度すべてのアセンブリをロードし続けますロードにかかる時間は、最初にロードするのと同じです。
アセンブリをメモリに永続的にロードして、メモリ常駐に向けたアセンブリの揮発性をオーバーライドすることを可能にするソリューションを探しています。
または、言及された問題を解決するアプリをユーザーが楽しく使用できるようにする他のソリューション。
IIS 6で、[アプリケーションプール]セクションに移動し、問題のASP.NETアプリケーションをホストするプールで[プロパティ]を右クリックします。 [パフォーマンス]タブに移動し、[アイドル状態になった後にワーカープロセスをシャットダウンする]チェックボックスをオフにします。
IIS 7で、[接続]ペインに移動して[アプリケーションプール]を見つけ、アプリケーションをホストするプールの[詳細設定]を選択します。 「アイドルタイムアウト」プロパティを見つけて「0」に設定します(これにより無効になります)。
デフォルトは20分の非アクティブです。ボックスのチェックを外すと、 AppDomain が ワーカープロセス によって読み込まれると、プロセスが終了しない限り、プロセスが停止することはありません。デフォルトでは、IISは プロセスをリサイクルします がメモリキャップなどの制限に達すると、新しい制限を開始し、すべてを「フェーズオーバー」します中断を最小限に抑えるために、古い要求が使用されなくなるまでの着信要求。
また、通常の状況で ASP.NETアプリケーションを存続させる ( 代替アーカイブバージョン )となる小さなc#クラスも作成しました。アプリケーション内で実行されるため、IISまたはその他のプロセスが明示的に強制終了されるのを防ぐことはできませんが、アプリケーションを「ホット」に保ちます。たとえば、アプリが長時間アイドル状態になることはありません。 IISがそれを遮断することを決定するのに十分です。
IIS構成(共有ホストなど))を直接制御できない場合は、小さなアプリケーションを別のシステム(たとえば、常時接続のワークステーション)で実行するのが最善の策です。これは、アプリケーションプールがタイムアウトにならないように、x分ごとにサイトにヒットします。特別なことは何もありません。コンソールアプリケーションで単純な WebRequest とwhile()ループで実行できます。
ASP .netの利点の1つは、オブジェクトの静的(共有)インスタンスを作成できることです。
外部プロセスの必要性を回避するために、(例として)global.asaxに静的タイマーを作成し、単純なWebRequestでドメインのページを呼び出すことができます。このようにして、プールの手動リセットが行われるまで、サイトは自分自身を維持します。
私は、Windowsタスクスケジューラを使用して、10分ごとに4つのサイトを維持する小さなC#コンソールアプリケーションを作成しました。人生は再び良いです。午前2時から5時の間にアプリを実行することはありません。問題が発生した場合でも、サーブがメモリのクリーンアップを実行できるようにするためです。私たちのサイトでは、とにかくその時間帯に誰かがいることはほとんどありません。