IIS6 ASP.NET 2.0アプリケーションキャッシュ - 大量データ用のデータ記憶域オプションとパフォーマンス

Question

のASP.NET 2.0サイトIIS6私は、アプリケーションキャッシュにキー/値のペアを格納したいと思います。各キーは常に5文字の長さの文字列で、各値の長さは15〜250文字の文字列です。

使用シナリオは、キーが存在する場合は値が使用され、それ以外の場合はデータベースを照会し、新しいキー/値をキャッシュに追加するか、またはいくつかのアプリケーションに基づいて既存のエントリを置き換える論理。

このシナリオでは、キャッシュサイズが約1000のエントリに達することを想定/要求しています。このサイズでは、安定性が増し、上記のように変更されることはめったにありません。私は、「パフォーマンステスト、それは自分が」誰もが、それはパフォーマンスに好適であるかどうかのキャッシュされた大量のデータのいずれかの経験を持っていない前に

：

（1）1つのCacheオブジェクトは、SortedDictionary<string, string>を含む使用しますまたは

（2）千のキャッシュオブジェクトの作成と使用辞書としてキャッシュ自体または

（3）それはちょうど問題のデータの量のために重要ではありませんが可能。エントリ数が10,000または100,000に増加した場合、あなたの回答は変わりますか？

多くのありがとうございます。

Answer 1

1000は大量のデータではありません。それは正常に動作しますが、このデータが要求間で共有される場合、同期について考える必要があります。実際には、へのアクセスを行うlockはおそらく問題ありませんが、必要に応じてより細分化することもできます。

しかし、作り付けのWebキャッシュ（HttpContext.Cache）も、これと同じ問題にアプローチし、中に構築されたすべてのスレッドの安全性を持っています。

を使用すると、データがソートされているケアを持っていない限りSortedDictionary<,>を使用しないでください。私はあなたがそうは思わない。

数字が大きくなるほど、私はredis/memcachedなどの店舗について、ローカルメモリをローカルショートカットとして考える傾向にあります。