1

AWS ECSのlinuxコンテナでASP.NetコアWeb APIが実行されています。このAPIは主にRedisからデータを取得しますが、存在しない場合はデータベースにフォールバックします(Googleのデータの99.99%がRedisキャッシュにある場合)。私は約1-2K RPSで合理的に高い負荷が加わっています。Stackexchange.Redisを使用してMGETコールの負荷が低下してゆっくりになる

このAPIは、リクエストごとにMGET(20-60の任意の場所)を介していくつかのキーを検索します。すべてが非同期であり、同期コードやWaitsなどのデッドロックが発生しやすいコードはありません。 RPSが増えるほど、速度が遅くなり、速度が遅くなります。私もPreserveAsyncOrder = falseを試しましたが、それは悪化しているようです。

私のRedisサーバー(Elasticacheにある)は問題ではないと考えられます。メトリックはわずか1%のCPU使用率しか示していません。また、私が作成するコンテナのインスタンスが増えるほど、レイテンシが低下し、サーバがボトルネックになっていても予想しないことが起こります。

TPLとSE.Redis(スレッドが固定されているかどうか、または.Net Coreに適用されているかどうかはわかりません)に潜在的なスレッド乗っ取りの問題があると聞いていました。 Web API呼び出しはまだ非同期ですが、SE.Redisへの呼び出しは同期です)。

MGET、inst:5、queue:199、qu:0、qs:199、qc:0、wr:0、wq:0、in:150304の​​タイムアウトが発生しました。 、ar:0、clientName:、serverEndpoint:10.55.148.227:6379、keyHashSlot:-2

これは.Net Coreのため、タイムアウト例外はフルスタックよりも情報量が少ないようですが、ワーカースレッドまたはIOCPスレッドを使用して、そこにボトルネックがないかどうかを確認します。

タイムアウトが頻繁に発生するにつれて、キュー/ qs:数が増加し、in:数も増加します。

数字が大きいと、スレッド処理の問題に遭遇する可能性があります。または、私のクライアントがネットワークに接続されているのでしょうか?

また、SE.Redisタイムアウトページに示されているように、redis接続用の接続プールを作成しようとしました。非常に小さな改善ですが、それでも同じ問題に直面しています。

ご協力いただければ幸いです。

答えて

-1

Redisはシングルスレッドです。あなたは単一のスレッドの負荷を増やしているので、応答が遅くなることは意味があります。 MGETは単一のバッチでの複数のGET操作にすぎません。したがって、各リクエストごとに20〜60 GET、1秒あたり2Kリクエストを実行する場合、Redisは約30〜120k ops /秒を実行します。

クラウドVMのCPUスループットまたはネットワーク飽和の最大スループットを達成していますか。

ランダムなキーを使用して負荷テストを行って、最大容量を最初に見つけて、それがアプリケーションに十分であるかどうかを知ってから、その周りをモデル化することができます。

ハッシュを使用すると、同様のデータを1つのキーにまとめることができます。また、より多くのサーバー(またはより多くのCPU上のインスタンス)でシャーディングを使用することもできます。 Redisクラスタは自動シャーディングを行います。

+0

これは問題ではないと確信しています。 1.上記の元の問題では、私はRedisサーバーがほとんど汗をかいていないようだと言いました。実際、別のマシンから接続すると、すべてがまだ高速です。 2.未処理のローカルキューがあることがわかります。これはサーバーとは関係ありません。 3。私は自分の図書館を書いていますが、これは対処されていないようであり、この問題を抱えていません。 – Cleverguy25

関連する問題