http-webhook-io-timeout

<acct-file>

Сколько ждать ответа приёмника при обмене
в конфигурации это строкаhttp-webhook-io-timeout 5sвнутри блока <acct-file>
Терпение при разговоре с приёмником

Строка ограничивает любую операцию обмена после того, как соединение установлено: отправку тела, ожидание ответа. Умолчание — 5s.

Это порог, за который цепляется медленный приёмник. Дозвон мгновенный, а ответ идёт долго, потому что принимающая сторона разбирает пачку синхронно. Пять секунд на разбор мегабайтной пачки — немного.

Правильное лечение — на стороне приёмника. Он должен отвечать сразу, а разбирать в фоне: MTA считает пачку доставленной только по ответу 2xx и всё это время держит соединение.

Первая половина пары — http-webhook-connect-timeout: она ограничивает дозвон, эта — разговор.

Главная ловушка — поднять порог вместо того, чтобы ускорить ответ. Медленный приёмник при большом пороге держит соединения узла дольше, и на потоке это упирается в число потоков отправки. Пачка при этом всё равно уходит с задержкой.
Что делает Хаб. Не пишет — умолчания хватает, и это следствие того, как устроен приёмник: TelemetryController проверяет токен, кладёт тело в кэш, ставит задачу и отвечает. Разбор пачки идёт отдельной задачей.

В комментарии к приёмнику это записано прямо: MTA считает пачку доставленной только при 2xx, и медленная аналитика тормозила бы чужой почтовый сервер.

Рекомендуемые значения

Порог поднимают только тогда, когда приёмник чужой и медленный:

Значение Когда
5s (умолчание) приёмник отвечает сразу, разбирает в фоне
до 60s приёмник чужой, разбирает синхронно, переписать нельзя

Свой приёмник надо чинить, а не обходить порогом.

Умолчание 5s и то, что порог касается любой операции обмена, — из руководства (§ 3.3.11.25). Правило «отвечать сразу, разбирать в фоне» — наше, оно же записано в приёмнике Хаба.
Пример в конфигурации
# чужой приёмник разбирает пачку синхронно и не укладывается
<acct-file /var/log/pmta/webhook.json>
    http-webhook-url https://partner.example.com/ingest
    http-webhook-io-timeout 30s</acct-file>
Для своего приёмника такая строка — признак, что его стоит переписать: принять, ответить, разобрать в фоне.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается1 ошибка▶

Разбирают пачку синхронно и поднимают порог

наш опыт

Чем чреватоСоединения узла держатся всё время разбора. На потоке это упирается в число потоков отправки, и накопление начинается снова, только позже.
Как заметитьПорог поднимали уже дважды, и каждый раз ненадолго помогало.
Как правильноПереписать приёмник: принять, ответить 2xx, разобрать в фоне.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
http-webhook-io-timeout <time-interval>
Значения
интервал времени
Умолчание
5s § 3.3.11.25
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<acct-file>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка живёт внутри своего <acct-file>. Разные потоки учёта могут уходить разным приёмникам с разной терпимостью.
Как проверить на узле
Меряем полное время ответа приёмника на пачку, похожую по размеру на настоящую:
curl -s -o /dev/null -w 'total=%{time_total}\n' -X POST --data-binary @batch.json URL
time_total заметно меньше порога — запас есть. Близко к порогу — приёмник разбирает синхронно, и правильнее исправить его.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Собрать телеметрию