0

Enterprise Library 5と、それがWebアプリケーションで提供するCacheManagerを使用しています。アプリケーションで高負荷テストを開始するまで、すべてが正常に機能しているようです。

IDに基づくキーを使用して、データベースからレコードをキャッシュしています。キャッシュから常に1つのアイテムを要求しているわけではなく、キャッシュからアイテムのリストを取得する必要がある場合があります。このために、Select(e => CacheManager.GetData(id_from_list))を作成し、キャッシュからアイテムのリストを返すLINQクエリがあります。ほとんどの場合、これは正常に機能しますが、負荷が大きい場合、キャッシュマネージャーがキャッシュからの読み取り操作と書き込み操作の両方で実行しているロックが原因で、GetDataメソッドがボトルネックになります。基本的に、一度に1つのスレッドのみがキャッシュからデータを読み取ることができます。

他の誰かが同じ問題に遭遇しましたか、そしてこれを克服する方法を見つけましたか?

注:実際にアイテムのリストをキャッシュし、リスト内のアイテムのIDからキーを作成しようとしました。これは実際に問題を解決し、cachemanager.getdataはもはやボトルネックではありません...しかし...多くのリストのキャッシュに各アイテムを何千回も持つ可能性があるため、これは明らかに良い解決策ではありません。

4

1 に答える 1

1

現在使用している排他的ロックの代わりに、読み取り/書き込みロック(この状況にはるかに適していると思います)を使用するようにCacheManagerを適応させることを検討してください。

http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlock.aspx

基本的に、読み取り/書き込みロックは、複数のリーダースレッドがデータに同時にアクセスする必要がある場合に適切であり、書き込みが発生した場合にのみ、着信リーダーがブロックされます。

ただし、これらには、書き込み不足など、負荷がかかると他の問題が発生します。読み取り/書き込みロックの実装に応じて、書き込みは常にすべての読み取りが最初に終了するのを待ちます-読み取りの一定のストリームでは、書き込みが発生する可能性はありません。

于 2012-07-26T18:39:31.697 に答える