1

私の最新のプロジェクトでは、データベースからデータを返す Web サービス API を作成する必要があります。

Techs are - SQL Server 08 R2 - WCF

データは主にキーと値のペアです。たとえば、ユーザー X のお気に入りの色を取得します。

負荷は大きくはありませんが、小さなフライでもありません - ピーク時には約 1,000 リクエスト/秒です。

私の最初の考えは、Redis をキャッシュとして使用することです。つまり、SQL Server に頻繁にアクセスしないことを意味します。しかし、私はこの構成からいくつかのベンチマークなどを取得しようとしてきましたが、それは素晴らしいことではなく、Redis が本当に私の問題に何らかの利益をもたらすかどうか疑問に思っています!

アーキテクチャは - 個別の db サーバー - WCF アプリケーション サーバー - IIS - Linux Redis サーバー

私のデスクトップで遊んでみると、Redis のベンチマークは ~ 20K ops/秒です。素晴らしいもの。

ただし、各呼び出しが Web サービスを通過することを考えると、WCF レイヤーを配置すると、300 ops/秒しか取得できません。良くない。確かに、Web サービス クライアント、Web サービス、およびデータベースはすべて同じマシン上にあるため、結果が歪む可能性があります。

また、実環境に移行する場合、ネットワークの遅延が大きな要因になります。

これらのリクエストをまとめることはできません。

だから - 私の質問 - 私はすべてRedisをキャッシュとして使用することに賛成です.この状況ではキャッシュを使用する必要があることを知っています.パフォーマンスを殺す？

どんなアドバイスでも大歓迎です！

ダンカン

4

2 に答える 2

0

System.Runtime.Cachingライブラリを使用する必要があると思われる .NET 4 を使用しているかどうかを確認することもできます。

1 台のサーバーを使用するとすぐに、優れた柔軟性が得られます。Web ファームが必要な場合、または同期、無効化、期限切れなどのように複雑な場合、分散キャッシュ (私の意見ではメモリ) を意味し、ローカル ストア (通常はメモリ内、ローカル) と分散ストアをサポートします。この名前空間を AppFabric でも使用して、目的のキャッシュを取得できます。

これがうまくいくことを願っています。

于 2012-05-21T06:46:57.317 に答える
0

レイヤーを個別にテストして調整しようと思います。データベースを含まないダミー データを使用して Web サービスをテストしますが、同様のデータ サイズと同時接続を使用します。データベースと同様に、予想されるユーザー ベースのサイズに一致するように合成データ (または可能であれば実際のデータ) を使用して、現実的な負荷とテーブル サイズでクエリを再度調整します。これら 2 つを一緒にテストし、注意深い測定を行って、変更が全体的なパフォーマンスにどのように影響し、ボトルネックがどこにあるかを確認できるようにします。最後に、キャッシング レイヤーを追加して、有効性を再度テストします。データベースがボトルネックである場合、キャッシングが役立つ可能性がありますが、Web サービス層が問題である場合、キャッシングは役に立たない可能性があります。キャッシュに Redis のみを使用している場合は、よりシンプルな memcached の方が適しているかもしれません。

于 2012-05-20T18:27:33.363 に答える