SQL サーバーから負荷を取り除くために、進行中のプロジェクトで「リードスルー」キャッシュとして使用するために NCache を評価しています。
クライアント側では、プロジェクトには最後のポーリング日時によって (サーバー側で) フィルター処理されたアイテムを受け取るポーリング ルーチンがあります。
ポーリングは、別のスレッドで一定間隔で発生します。
クライアント側
1) 初回フェッチの擬似コード:
- すべての既存のアイテムを取得する
- LastHandledDateを今に設定
2) 初回以外のフェッチ (ポーリング スレッド)
- LastHandledDateの後に作成された既存のアイテムをフェッチする
- LastHandledDateを現在に更新する
サーバー側では、ポーリング クエリを受信すると、次の疑似コードが実行されます。
- CreationDate >= LastHandledDateで一致するすべてのアイテムの NCache をクエリします。
- IF クエリの結果が空です
- CreationDate >= LastHandledDateで一致するすべての項目について SQL データベースにクエリを実行する
- クエリが空でない場合は、NCache を SQL クエリの結果で更新します
- SQL クエリの結果を返す
- ELSE は NCache クエリの結果を返します
NCache をクエリするには、linq プロバイダーを使用しています。クエリは SQL クエリに似ています。
SELECT * FROM Messages WHERE Message.SessionId = 1234 AND Message.EntryDate >= ‘2012-10-6’
編集:テスト中、クライアント側には一定の速度で新しいアイテムを追加するスレッドがあります
サーバー側の部分は、Web サービス (IIS の WCF) でホストされます。
上記のポーリング設定を 100 クライアントで約 1 時間負荷テストした後、Web サービスが実行していた 1 秒あたりの要求数が着実に減少していることに気付きました。
NCache からの読み取りのみを使用して上記のセットアップを実行し、SQL 読み取りをまったく行わずに (サーバー側の擬似コードの段落2を使用せずに)、要求/秒で同じ減少パターンが得られました。
いくつか質問があります:
- NCache のクエリ パフォーマンスは、キャッシュ内のオブジェクトの総数に依存するようです。これは同様のソリューション (NoSQL / 分散キャッシュ) に当てはまりますか?
- クエリ速度が最適化されている NoSQL/分散キャッシュ ソリューションはどれですか?
- たぶん、NCache では、クエリをより最適化することができますか?
- おそらく私は何かを見逃しています - そして私の分散キャッシュの使用パターンは間違っています - 私のユースケースで NCache などの分散キャッシュを効率的に使用するにはどうすればよいですか?