Операция выполнена!
Закрыть
Хабы: DevOps, Linux, Системное администрирование, Настройка Linux

Когда API долго ждёт зависимость, хочется сократить таймаут. Запрос быстрее получит ошибку, освободит ресурсы и перестанет висеть. Но сразу возникает следующий вопрос: что приложение сделает после этой ошибки? Если оно без паузы повторит тот же вызов, короткое ожидание может превратиться в большую очередь на другой стороне.

В моём проекте Prod is Down есть учебный кейс с такой цепочкой: первое исправление вскрывает проблему с повторами. Для этого разбора я собрал отдельный локальный стенд и сравнил четыре варианта настроек.

Условия простые: шесть клиентов обращаются к небольшому TCP-сервису на 127.0.0.1. Одновременно сервис обрабатывает три задания. Первые две секунды обработка занимает 250 мс, затем возвращается к 20 мс. Каждый клиент начинает следующую операцию после завершения предыдущей и небольшой паузы. Каждый вариант запускается на шесть секунд с пустой очередью.

Важное условие: принятое задание продолжает выполняться, даже если клиент уже закрыл соединение. Так устроена наша тестовая зависимость - отмену принятой работы мы здесь не реализуем. В конкретном приложении это поведение нужно проверять отдельно.

Сначала оставляем таймаут в одну секунду. Медленный вызов успевает завершиться: первая операция получает ответ примерно через 256 мс. За весь прогон клиенты выполнили 513 успешных операций. Таймаутов не было, а максимум одновременно обрабатываемых и ожидающих заданий составил шесть.

Теперь меняем только время ожидания: вместо 1000 мс ставим 50 мс. Повторы по-прежнему бесконечные, паузы между ними нет. В настройках нашего стенда это MAX_ATTEMPTS=0 и BACKOFF_BASE=0. Ноль здесь означает отсутствие ограничения, у других библиотек такое значение может иметь другой смысл.

Читать далее
Читайте также
НОВОСТИ

ПИШИТЕ

Техническая поддержка проекта ВсеТут

info@vsetut.pro