App_Code内の静的変数に格納された大量のキャッシュオブジェクトを含むWebサイトがあります。App_Codeの変更を本番Webサーバーにプッシュするたびに、IISプールがリサイクルされ、キャッシュがフラッシュされます。ただし、.aspxファイルと.aspx.csファイルへの変更をプッシュすると、キャッシュはフラッシュされません。
App_Codeで参照できるようにするには、1日に数回更新される一連のクラスが必要です。IISを循環させてキャッシュをフラッシュせずに1日に数回更新できるApp_Codeのセクション、またはApp_Code内からApp_Codeの外部のクラスを参照する機能のいずれかが必要です。
私の問題に合う解決策はありますか？
App_Codeまたは/bin/を更新すると、常にアプリケーションプールがリサイクルされると思います。.aspx.csファイルの更新によってアプリケーションプールがリサイクルされない展開シナリオがあり、ページタイプ自体を参照できる場合は、コードを.aspxに移動できます。 csファイルなので、リサイクルが行われないようにします。しかし、それは醜い選択かもしれません。
1つの提案は、毎日必要なソースコードの更新の数を減らすために設計を修正することです。おそらく、XMLまたはデータベースストレージを使用し、アプリケーションをもう少し一般的で、バイナリ更新の傾向が少ないように設計します。
または、アプリケーションをいくつかの小さな仮想アプリケーションに分割することもできます。これを行うには、より高いレベルの作業が必要になる可能性がありますが、この場合、アプリケーションがより細分化されている場合は、デプロイごとにアプリ全体をリサイクルする必要はありません。展開によって影響を受けたモジュールをリサイクルするだけで済みます。
もう1つの提案は、クラスター化されたサーバーアーキテクチャをセットアップすることです。1つのクラスターノードに適用するように展開をスケジュールし、スケジュールされた更新が行われている間は他のノードのみをアクティブにして、最初のノードの更新が完了したら、アプリプールをリサイクルして2番目のノードに更新をロールアウトします。
もう1つの提案は、可能であれば、展開時間をオフピーク時間より短くすることです。
多くの開発変更が行われているという理由だけで、頻繁な更新が行われていますか？
もう1つの角度は、HttpRuntimeキャッシュの代わりに分散キャッシュソリューションを使用することです。
HttpRuntimeキャッシュには、2つの大きな欠点があります。
1）アプリドメインがリサイクルされるとフラッシュされます。これは、App_Codeを変更しなくても、デフォルトでは29時間ごとに実行されます。
2）単一のWebサーバーにローカライズされています。したがって、Webサーバーをより大きなWebファームに拡張する必要がある場合、キャッシュエントリがすべてのWebサーバー間で同期されていないため、キャッシュの効果はますます低下します。
分散キャッシュソリューションは、Web層とバックエンドデータソースの間に別個のキャッシュレイヤーを作成することにより、これらの問題を回避します。
ソリューションの例：
もちろん、これによりアーキテクチャがより複雑になり、より多くのハードウェアまたはVMが必要になります。