フォルダーの残りの部分とは別にコンパイルするapp_codeのセクションを持つことはできますか？

Question

app_code内の静的変数に格納されている膨大な量のキャッシュオブジェクトを備えたウェブサイトがあります。 App_Codeの変更を生産WebServersにプッシュするたびに、IISプールをリサイクルしてキャッシュをフラッシュします。 .aspxおよび.aspx.csファイルへの変更をプッシュアウトすると、キャッシュをフラッシュしません。

app_codeで参照できるようにするには、1日に数回更新されるクラスをたくさん持っている必要があります。 IISをサイクリングしてキャッシュをフラッシュせずに1日に数回更新できるAPP_CODEのセクション、またはAPP_CODE内からapp_code以外のクラスを参照する機能をご希望にします。

私の問題に合った解決策はありますか？

Answer 1

app_codeまたは / binの更新 /私が信じているアプリケーションプールを常にリサイクルしてください。 .aspx.csファイルの更新がアプリケーションプールをリサイクルしない展開シナリオがあると言っている場合、ページタイプ自体を参照できる場合は、おそらくコードを.aspxに移動できます。 CSファイルは、リサイクルが発生しないようにするためです。しかし、それは醜い選択かもしれません。

提案の1つは、デザインを修正して、毎日必要なソースコードの更新の数を減らすことです。おそらく、XMLまたはデータベースストレージを使用し、アプリケーションを設計して、もう少し一般的で、バイナリの更新が発生しやすくなりやすくなります。

または、アプリケーションをいくつかの小さな仮想アプリケーションに分割してください。これを行うには努力のレベルが高くなる可能性がありますが、この場合、アプリケーションがよりコンパートメント化されている場合、すべての展開でアプリ全体をリサイクルする必要はありません。展開で影響を受けたモジュールをリサイクルするだけです。

別の提案は、クラスター化されたサーバーアーキテクチャをセットアップすることです。展開をスケジュールして、1つのクラスターノードに適用され、スケジュールされた更新が発生している間は他のクラスターノードのみをアクティブに保ち、最初のノードアップデートが完了したら、2番目のノードの更新をロールアウトします。アプリプールがリサイクルされます。

もう1つの提案は、それが実行可能であれば、展開時間をオフピーク時間を短縮することです。

多くの開発の変更が起こっているからといって、頻繁な更新は起こっていますか？

Answer 2

別の角度は、HTTPruntimeキャッシュの代わりに分散キャッシュソリューションを使用することです。

httpruntimeキャッシュには2つの大きな欠点があります。

1）アプリドメインがリサイクルするとフラッシュされます。これは、app_codeを変更しなくても、とにかく29時間ごとにデフォルトで行われます。

2）単一のWebサーバーにローカライズされています。したがって、Webサーバーがより大きなWebファームにスケーリングする必要がある場合、キャッシュエントリがすべてのWebサーバーで同期していないため、キャッシュはますます効果的になります。

分散キャッシュソリューションは、Web層とバックエンドデータソースの間に別のキャッシュレイヤーを作成することにより、これらの問題を回避します。

ソリューションの例：

• memcached
• Redis
• Oracle Coherence（コマーシャル）

もちろん、これにより、より複雑なアーキテクチャが生じ、より多くのハードウェアまたはVMが必要になります。