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