Azure Table Storage RetryPolicy вопросы

Question

Пара вопросов об использовании RetryPolicy с Table Storage,

1. Рекомендуется ли использовать RetryPolicy всегда, когда это возможно, поэтому используйте ctx.SaveChangeWithRetries () вместо ctx.SaveChanges ()соответственно, когда вы можете?

2. Когда вы используете RetryPolicy, например,

   ctx.RetryPolicy = RetryPolicies.Retry (5, TimeSpan.FromSeconds (1));

Какие значения обычно используют люди для retryCount и TimeSpan?Я вижу, что 5 попыток и 1 секунда TimeSpan являются популярным выбором, но будут ли 5 ​​повторов по 1 секунде слишком длинными?

Спасибо,

Луч.

Answer 1

Я думаю, что это сильно зависит от вашего приложения и требований.Ошибки тайм-аута для ATS случаются настолько редко, что если политика повторных попыток не помешает иметь место и будет редко использоваться в любом случае.Но если происходит что-то подозрительное, это может избавить вас от необходимости отлаживать странные ошибки.

Теперь я хотел бы предложить, чтобы вначале вы вообще не включали RetryPolicy и вместо этого имели трассировку, чтобы вы могли видетьлюбые проблемы с сохранением к САР.Как только вы стабилизируете, использование RetryPolicy может быть хорошей идеей для обхода некоторых проблем во время выполнения на стороне ATS.Просто убедитесь, что вы не маскируете свои собственные проблемы с RetryPolicy.

Answer 2

Если ваш клиент обращен к пользователю как к веб-странице, вы, вероятно, хотели бы использовать линейную повторную попытку с коротким ожиданием (миллисекундами) между каждой повторной попыткой, если ваш клиент на самом деле не относится к пользовательской серверной службе и т.д.скорее всего, вы захотите использовать экспоненциальные повторные попытки, чтобы не перегружать службу хранения таблиц, например, если она уже выдает ошибки 5xx из-за высокой нагрузки.

Используя последний SDK клиента хранилища Azure, если вы не определяете политику повторных попыток в своих запросах к таблице через TableRequestOptions, тогда используется политика повторных попыток по умолчанию, то есть экспоненциальная повторная попытка.SDK делает 3 попытки в общей сложности для ошибок, которые он считает повторяемыми, и в общей сложности это занимает более или менее 20 секунд, если все попытки не удаются.