🦮 Задача 3: Ускоряем тормозящий канал.
Мы научились работать с ретраями и таймаутами по отдельности. Что ж давайте
скомбинируем эти знания! 🔥

Теперь у нас все так же есть сервис, задержка до которого в 10% случаев составляет 1 секунду.

❓Но теперь вопрос такой: какую минимальную задержку выбрать и сколько минимально ретраев нужно, чтобы в итоге 95й перцентиль задержек был меньше 200мс и при этом чтобы > 98% запросов возвращали успех?
 
Обратите внимание, что при этом сервис не выбрасывает ошибок, просто иногда подвисает на секунду.

Моя эмоциональная ремарка: Эта задача на мой взгляд просто охуительна тем, что позволяет вам получить устойчивое качество связи, при довольно неустойчивом сервисе. Да, опустим пока что ту подробность, что мы при этом повышаем нагрузку на сервис. 🌝 Но чисто математически это звучит прям пиздатенько! Прикиньте, вы сейчас придумаете штуку, которая ускорит тормозящее говно только за счет того что вовремя отсеет лишнее!

✅ Ответ как всегда тут:
Для начала вычислим необходимый таймаут. Это мы сделаем по методу из прошлой статьи. Получится таймаут в 180 мс
 
Этот таймаут будет отсеивать примерно 10% запросов и выбрасывать ошибку TimeoutException. А теперь нам и пригодится формула из первой статьи!
Высчитываем для одного ретрая:
q = 0.1 - процент ошибок
n = 2 - количество попыток получить ответ вовремя (один изначальный запрос + один ретрай)
1-q^n = 1 - 0.1^2 = 0.99 – вполне достаточно по нашим требованиям

P.S.: Кстати, пока считал тут все, проверял результаты на практике и перепутал
retryPolicy и timeoutPolicy местами. Из-за этого ничего не работало. Так что не путайте политики местами, надо вот так:
Policy.WrapAsync(retryPolicy, timeoutPolicy); ✅
А не так
Policy.WrapAsync(timeoutPolicy, retryPolicy); ❌

#ресайленс