Как уже упоминалось в этом вопросе, в ActivityOptions есть четыре различных параметра времени ожидания, и различия между ними могут быть не совсем ясны для нового пользователя Cadence. Давайте сначала кратко объясним, что это такое:
ScheduleToStartTimeout: эта конфигурация задает максимальную продолжительность между временем, запланированным для рабочего процесса, и рабочим действия, чтобы начать его выполнение. Другими словами, он настраивает время, которое задача проводит в очереди. StartToCloseTimeout: этот параметр определяет максимальное время, затрачиваемое работником действия с момента, когда он получает задачу, пока не сообщит о ее завершении. на сервер Cadence. ScheduleToCloseTimeout: в этой конфигурации указана сквозная продолжительность тайм-аута для действия с момента, когда он запланирован рабочим процессом, до его завершения работником. HeartbeatTimeout: Если ваше действие является сердцебиением, эта конфигурация в основном указывает максимальную продолжительность, в течение которой сервер Cadence будет ожидать сердцебиение, прежде чем предположить, что работнику не удалось.
Как правильно выбрать значение времени ожидания
Выбор StartToCloseTimeout довольно прост, если вы знаете, что он делает. По сути, вы должны сделать это достаточно долго, чтобы деятельность могла завершиться при нормальных обстоятельствах. Следовательно, вы должны учитывать все, что может повлиять на время, затрачиваемое работником, на задержку вашего нисходящего потока (ie. Services, network et c.). С другой стороны, вы должны стремиться к тому, чтобы сохранить это значение как можно меньшим, чтобы сделать вашу комплексную систему более отзывчивой. Если вы не можете сделать этот тайм-аут менее пары минут (в идеале, 1 минуту или меньше), вам следует рассмотреть возможность использования конфигурации HeartbeatTimeout и реализовать сердцебиение в своей деятельности.
ScheduleToCloseTimeout также легко понять, но чаще встречаются проблемы, вызванные выбором менее чем идеального значения здесь. Поэтому важно обеспечить момент, чтобы уделить дополнительное внимание этой конфигурации.
По сути, вы должны рассмотреть все, что может создать отставание в очереди задач деятельности. Некоторые общие события, которые вносят свой вклад в отставание:
- Снижение пропускной способности рабочего пула из-за проблем с развертыванием, обслуживанием или сетью.
- Пики задержки в нисходящем направлении, которые могут увеличить время требуется для выполнения каждой задачи действия, что затем снижает пропускную способность рабочего пула.
- Значительный всплеск числа экземпляров рабочего процесса, которые планируют действие; особенно если одна из вышестоящих служб также является асинхронным процессором очереди / потока, который может создать свой собственный журнал невыполненных работ и внезапно начать обрабатывать его с очень большим объемом.
В идеале ни одна операция не должна прерываться во время ожидания в очереди задач, особенно если резервная копия очереди и действие настроено на повторную попытку. Потому что повторные попытки добавили бы больше задач активности в очередь и впоследствии усложнили бы восстановление после отставания или еще хуже. С другой стороны, во многих случаях использования бизнес-требования действительно ограничивают общее время, которое может занять система для обработки операции. Поэтому, как правило, неплохая идея стремиться к высокой ScheduleToCloseTimeout, если позволяют бизнес-требования. В зависимости от вашего варианта использования может не иметь смысла держать вашу активность в очереди более нескольких минут, или было бы вполне нормально держать ее там в течение нескольких дней до истечения времени ожидания.