BizTalk Inadequate Latency - Response Time Issue Causing C # in WCF-Published-Orchestration

Question

Calling a WCF public orchestration from a C # program is usually the second second response time. However, in some cases, this may take 20-50 seconds between calling the C # program and the first trace message from the orchestration. C #, which makes WCF calls, runs under HIS / HIP (Host Integration Services / CICS Host-Initiated Processing).

Almost every time I restart the HIS / HIP service, we have a very slow response time and therefore a timeout in CICS. I am also afraid that this could happen during the day if something “cools down” - in other words, it is possible that things are cached. Even the first JIT compilation shouldn't take 20-50 seconds, if they? Another thing that seems strange is that the slow response time seems to be an orchestration load that runs on BizTalk, not the HIP / Service that I used.

The fear is that when we go live, the first user in the morning (or after the "cold spell" will receive a timeout). The second time they try it after a timeout, it is always fast.

I did some tests, restarting each of the following: 1) BizTalk Services 2) IIS 3) HIS / HIP Transaction Integrator (HIP Service)

Restarting any of them tends to cause an approximately 20 second delay. Restarting all 3 is like a kiss of death - about 60 seconds before the first track from the orchestration begins.

HIP always gives its first trace quickly, even when the HIP service restarts. I don’t know why restarting HIP slows down the start of orchestration.

Thanks,

Neal Walters

Answer 1

I also saw this behavior with the MQSeries adapter. After a period of inactivity, COM + components that provide communication with the MQSeries will be disconnected due to inactivity.

What we had was a 10 minute timer that would trigger some kind of safety message. I do not know if you have a non-destructive call that can be sent, or if you can create it in the system just for this purpose.

Answer 2

I have the same problem with a BizTalk thread, which should work after 2 seconds, but when it has not been used for some time, reloading the dll into the cache caused a timeout.

We found a solution in the MS Documentation on the configuration of the orchestra , which explains how to avoid unloading the dll libraries:

Using the SecondsIdleBeforeShutdown and SecondsEmptyBeforeShutdown from AppDomainSpecs and assigning the required DLLs to the ExactAssignmentRules or PatternAssignmentRules , you can constantly load your dlls, and perhaps you can avoid calling the caller.

Note that when you restart the BizTalk node, the dll will load again.