表の記憶域でRetryPolicyを使用して上のカップルの質問、AzureテーブルストレージRetryPolicyの質問
それはあなたが、それ故にctx.SaveChangeWithRetriesを（使用することができますいつでもRetryPolicyを使用することをお勧めします）（）あなたができるときはいつでもそれに応じて？
あなたがRetryPolicy、例えば、
ctx.RetryPolicy = RetryPolicies.Retry（5、TimeSpan.FromSeconds（1））を使用して行います。
retryCountとTimeSpanには通常どのような値が使用されていますか？ 5回の再試行と1秒のTimeSpanが一般的な選択ですが、5秒ごとに長すぎると再試行しますか？
ありがとう、
レイ。
私はこれがあなたのアプリケーションと要件に大きく依存していると思います。 ATSに対するタイムアウトエラーは、再試行ポリシーが適切な位置にあることを傷つけず、とにかくほとんど利用されないような場合にはめったに発生しません。しかし、何か怪しげなことが起こっている場合、奇妙なエラーをデバッグする必要がなくなります。
ここでは、RetryPolicyを有効にしないで、代わりにトレースを行い、ATSに対する永続性の問題を確認できるようにすることをお勧めします。安定したら、RetryPolicyを置くことは、ATS側でいくつかの実行時の不具合を回避するためには良い考えかもしれません。 RetryPolicyを使用して問題を隠蔽していないことを確認してください。
クライアントがWebページのように向いている場合、クライアントが実際にバックエンド以外のサービスに直面している場合など、再試行のたびに短い待ち時間（ミリ秒）で線形再試行を使用することをお勧めします。例えば、負荷が高いなどの理由で5xxエラーが発生している場合に備えて、テーブルストレージサービスが過負荷にならないように、指数関数の再試行を使用したいと考えています。
最新のAzure StorageクライアントSDKを使用すると、TableRequestOptionsでテーブルリクエストにリトライポリシーを定義しないと、指数再試行のデフォルトのリトライポリシーが使用されます。 sdkは、再試行可能と見なすエラーの合計で3回の再試行を行い、すべての再試行が失敗した場合、合計で20秒を要します。