Сервис тормозил. Уменьшили таймаут — стало хуже
Habr ·
Когда API долго ждёт зависимость, хочется сократить таймаут. Запрос быстрее получит ошибку, освободит ресурсы и перестанет висеть. Но сразу возникает следующий вопрос: что приложение сделает после этой ошибки? Если оно без паузы повторит тот же вызов, короткое ожидание может превратиться в большую очередь на другой стороне. В моём проекте Prod is Down есть учебный кейс с такой цепочкой: первое исправление вскрывает проблему с повторами. Для этого разбора я собрал отдельный локальный стенд и сравнил четыре варианта настроек. Условия простые: шесть клиентов обращаются к небольшому TCP-сервису на 127.0.0.1. Одновременно сервис обрабатывает три задания. Первые две секунды обработка занимает 250 мс, затем возвращается к 20 мс. Каждый клиент начинает следующую операцию после завершения предыдущей и небольшой паузы. Каждый вариант запускается на шесть секунд с пустой очередью. Важное условие: принятое задание продолжает выполняться, даже если клиент уже закрыл соединение. Так устроена наша тестовая зависимость - отмену принятой работы мы здесь не реализуем. В конкретном приложении это поведение нужно проверять отдельно. Сначала оставляем таймаут в одну секунду. Медленный вызов успевает завершиться: первая операция получает ответ примерно через 256 мс. За весь прогон клиенты выполнили 513 успешных операций. Таймаутов не было, а максимум одновременно обрабатываемых и ожидающих заданий составил шесть. Теперь меняем только время ожидания: вместо 1000 мс ставим 50 мс. Повторы по-прежнему бесконечные, паузы между ними нет. В настройках нашего стенда это MAX_ATTEMPTS=0 и BACKOFF_BASE=0. Ноль здесь означает отсутствие ограничения, у других библиотек такое значение может иметь другой смысл. Читать далее