現在、キャッシュされたオブジェクトの量が多いため、問題に直面しています。ERP システム (オンライン ショップ用) からデータをキャッシュすると、メモリの最大量に達すると IIS によって Web ページが更新され、キャッシュされたすべてのオブジェクトが失われます。これにより、キャッシュのアイデアが少し問題になるため、別のソリューションでオブジェクトをキャッシュするソリューションを探しています。
Microsoft の AppFabric は、Windows Server ライセンスに既に含まれているため、非常に優れたソリューションであることがわかりました。
MemoryCache クラス (現在のキャッシングのソリューション) の代わりに AppFabric Velocity を使用すると、大きなパフォーマンスの問題が発生するのではないかと心配しています。
だから私の質問は今、これは私たちの問題の解決策ですか、それとも私はここで考えすぎて、AppFabric のパフォーマンスは十分に速いのでしょうか?
Grid Dynamics は、ここでAppFabric の使用に関する優れたレポートを作成しました。特定のキャッシュ操作の数値はわかりませんが、レポートでは、AppFabric のパフォーマンスに関して優れた数値が示されました。あるテストでは、キャッシュのサイズがキャッシュ操作のパフォーマンスにどのように影響するかを確認したいと考えていました。データを読み取るだけでは、キャッシュ操作のパフォーマンスにほとんど、またはまったく影響がありませんでした。更新すると、キャッシュ操作のパフォーマンスに影響がありましたが、とんでもない量ではありませんでした. オブジェクトのサイズとパフォーマンスをテストすると、明らかに、オブジェクトが大きくなるとパフォーマンスが低下します (ここではスループット パフォーマンス)。全体として、このレポートには、AppFabric キャッシュのパフォーマンスが優れていることを示す堅実なテストと統計が含まれています。
いいえ、Grid Dynamics は結果を他の製品と比較しませんが、さまざまなテストで AppFabric キャッシュのパフォーマンスがどのようなものかを示しています。それらには、さまざまな使用シナリオで人々を助けるための詳細を提供できる、特に便利な付録セクションがあります。
いつものように、IIS インスタンスと同じマシン上にないソリューションを使用すると、キャッシュからのセッション データのフェッチに少し時間がかかりますが、それはわずかな時間です。
私があなたの状況を理解している場合、オブジェクトをメモリにキャッシュし、アプリケーションロジックに従って、またはキャッシュがいっぱいになり始めたときにそれらを期限切れにするオブジェクトキャッシングソリューションが利用可能です。
特に「インプロセス」キャッシュについて話す場合、Appfabric はこの点であまり成熟した製品ではありません。クライアント キャッシュが必要です。これは実際には分散キャッシュのサブセット (キャッシュされたすべてのオブジェクトを意味します) であり、"in proc" に存在し、分散キャッシュとの同期が維持されます。
私がお勧めする解決策の 1 つは、NCache を分散キャッシュとして使用し、そのクリネット キャッシング機能を ERP オブジェクトに使用することです。