2016-12-08 5 views
3

SS 4.5.2を使用して、ServiceStack APIをLinux/Mono(自分のハードウェア上)からAzure Appサービスに移動しています。私のRedisキャッシュはLinux VM上で動作する3.2です。私はAzure Redisサービスを使用してでないです。ServiceStack.RedisタイムアウトAzure

私はこの例外をランダムに一見スローされる見ている:

RedisException - 午前〇時00分03秒

の超過タイムアウト例外は、認証属性を使用してサービスからスローされているようですすべてのスタックトレースには、 "ServiceStack.AuthenticateAttribute.Execute"が含まれています。"ServiceStack.ServiceExtensions.GetSession"およびが含まれています。私は現在、セッションストレージ用にRedisのみを使用しているので、このビットは驚くことではありません。

いくつかの時間のために生産に私の以前のLinux /モノラルのセットアップに取り組んできた、次のように私は私のICacheClientを登録している:私はSSフォームにポストを見た

container.Register<IRedisClientsManager>(c => 
    new RedisManagerPool("SomeRedisMachine:6379")); 

container.Register(c => c.Resolve<IRedisClientsManager>().GetCacheClient()); 

https://forums.servicestack.net/t/redis-exception-exceeded-timeout-of-00-00-03/2301 - しかし、これはAzure Redisサービスを使用している場合にのみ適用されますが、私はそうではありません。この情報が与えられ

は、私は答えを見つける必要がありますいくつかの質問があります:上位階層にRedisのVMを移動

  • んが この上の任意のプラスの影響を与えますか?現在、VMは利用可能な最小のものの1つです。私は今日これを試してみます。 更新:VMサイズを増やしても問題は解決しないようです。
  • Redis VMとApp Serviceの間のレイテンシが大きすぎますか?同じデータセンター内にあるので、これは問題だとは思いません。
  • 私は考慮する必要があるLinux/MonoとAzure App Service(Windows、おそらく何らかの改造されたIISに裏打ちされている)の間に若干の違いがありますか?

ありがとうございました!

更新

mythzの提案を1として、私はSSのv4.5.4にアップデートを行いました。ただし、上記の更新されたタイムアウトと一貫して若干異なるメッセージ(00:00:10の超過タイムアウト)が発生しても、例外はスローされます。

Azure Redis Service(Linux VMとは対照的)をターゲットにすることにしました。私はこれまで、ServiceStack 4.5.2または4.5.4のRedisに関連するエラーは見られませんでした。多分、マイクロソフトが独自のRedisサービス用に使用しているホストがあれば、ネットワーク接続が良好で、アプリケーションサービスを処理するクラスタに近い場合もあります。

答えて

2

Redis TimeoutExceptionは、不健全な環境でRedis ClientがTCP接続を確立できないという症状です。これは、Redis-ServerインスタンスまたはNetworkが過負荷または信頼できないことが原因です。またServiceStack.Redisのv4.5.4の+から新しいデフォルトのタイムアウトである

RedisConfig.DefaultRetryTimeout = 10 * 1000; 

あなたはRedisのクライアントにとの接続を行うために多くの時間を与えるためにタイムアウトを増やすことができます。

+0

私の質問は今後の研究の結果で更新されました。私はLinux VMがどこにいても、いつでもどこでもネットワーク状況に関係していることに同意します。Azure Redisサービスは完璧に機能します。 – SeanH

関連する問題