1

私は可能な限り少しのパフォーマンスを絞り出そうとしています。そのため、カスタム ViewLocationCache を見ていました。

デフォルトのものはルックアップを に保存します。HttpRuntime.Cache可能であれば、そこに関連するオーバーヘッドを回避したかったのです。Html.RenderPartial主に、ループで呼び出すビューがいくつかあるためです。

私がやろうと思ったのは、ConcurrentDictionary代わりに a を使うことでした。私は MVC のソースを調べましたが、これが悪い理由がわかりませんし、考えることもできません。Azure にデプロイするので、AppDomain はデプロイ時にリセットされることが保証されており、バッド ヒットについて心配する必要はありません。

なぜこれを行うべきではないのか、痛々しいほど明らかな何かが欠けていますか?

//fastCache is a static ConcurrentDictionary<string, string>
public string GetViewLocation(HttpContextBase httpContext, string key)
{
    return fastCache[key];
}

public void InsertViewLocation(HttpContextBase httpContext, string key, string virtualPath)
{
    fastCache[key] = virtualPath;
}
4

1 に答える 1

3

HttpRuntime.Cache並行辞書では取得できない、構成可能なきめ細かい有効期限ポリシーを提供します。たとえば、アイテムに定義した優先度に基づいてサーバーのメモリが不足し始めた場合、アイテムは期限切れになりますが、並行辞書はアプリケーションがメモリ不足エラーで爆発するまで成長し続けます。しかし、それが何らかの形でアプリケーションのパフォーマンスに悪影響を及ぼしていると判断した場合HttpRuntime.Cache(これはかなり驚くべきことです)、代替手段を探す正当な理由のように思えます。HttpRuntime.Cache単純なスレッド セーフ ハッシュテーブル以上のものがあることを忘れないでください。

于 2012-05-11T06:13:00.270 に答える