Недостаточная латентность BizTalk - проблема времени ответа, вызывающая C# в WCF-Опубликованная-оркестровка

Question

Вызов опубликованной публикации WCF из программы C# обычно является временем ответа второй секунды. Однако в некоторых случаях это может занять 20-50 секунд между вызовом программы C# и первым сообщением трассировки из оркестровки. C#, который запускает вызовы WCF, выполняется под HIS/HIP (Host Integration Services/CICS Host-Initiated Processing).

Практически каждый раз, когда я перезапускаю службу HIS/HIP, у нас очень медленное время отклика и, следовательно, тайм-аут в CICS. Я также боюсь, что это может произойти в течение дня, если что-то «остынет» - другими словами, возможно, что вещи кешируются. Даже первые компиляции JIT не должны занимать 20-50 секунд, если они? Другая вещь, которая кажется странной, заключается в том, что медленное время отклика, по-видимому, является нагрузкой оркестровки, которая работает под управлением BizTalk, а не HIP/Service, которую я задействовал.

Страх в том, что когда мы идем в прямом эфире, первый пользователь утром (или после «холодного заклинания» получит таймаут). Во второй раз, когда они пробуют его после тайм-аута, это всегда быстро.

Я сделал несколько тестов путем перезапуска каждого из следующих: 1) BizTalk услуги 2) IIS 3) HIS/HIP Transaction Integrator (HIP Service)

Перезапуск любой один из них, как правило, вызывают примерно 20-секундную задержку. Перезапуск всех 3 похож на поцелуй смерти - примерно за 60 секунд до начала первого следа из оркестровки.

Программа HIP всегда дает свой первый след быстро, даже когда служба HIP перезапускается. Не знаю, почему перезапуск HIP замедляет начало оркестровки.

Спасибо,

Нил Walters

Answer 1

Я видел такого рода поведение с помощью адаптера MQSeries, а также. После периода бездействия компоненты COM +, которые обеспечивают связь с MQSeries, будут отключены из-за неактивности.

То, что у нас было, было 10-минутным таймером, который заставил бы какое-то сообщение о сохранности. Я не знаю, есть ли у вас неразрушающий вызов, который можно отправить, или если вы можете построить его в системе только для этой цели.

Answer 2

У меня такая же проблема с потоком BizTalk, который должен работать через 2 секунды, но когда он не использовался в течение некоторого времени, перезагрузка dll в кеш вызвала тайм-аут.

Мы нашли решение в Orchestration Engine Configuration документации MS, где они объясняют, как избежать выгрузки DLLs:

Используя опцию SecondsIdleBeforeShutdown и SecondsEmptyBeforeShutdown от AppDomainSpecs и присваивания искомых библиотек DLL в секциях ExactAssignmentRules или PatternAssignmentRules, вам могут быть постоянно загружены ваши dll, и, возможно, вы можете избежать обращения к вызывающему абоненту.

Учтите, что при перезапуске узла BizTalk DLL будет загружена снова.