BizTalk service at partial capacity of it's (apparent) virtual resources RRS feed

  • Question

  • Hello forum, I have a situation that I am not sure how to proceed, so asking for help/guidance.

    My client has this virtualized production server, was configured and provisioned long before so I am not exactly sure of all the details. We were in charge of deploying a new application so we don't have a reference on previous behavior. The engine uses a large but simple schemas EDI that are also mapped using all built-in functionality.

    We ran a fairly large message to be transformed and it is taking long to process. As far as we can see, there is no throttling condition as biztalk never stops processing and try to free resources, although I have not checked directly using perfmon, this is not the case (I think). The orchestration service is active (not dehydrated) and just keeps going and going. The issue here is that just 25% of the apparent full fledge capacity of the server is used regarding processing power.

    In the following image is the processor configuration of the virtual environment and also, a screen of the service as it continues to go around 25~28% of cpu, but is stuck in there, never reaching any higher. At this point I am not sure if theres configuration in my host/host instance settings or it has something to do with said provisioned virtual environment.

    Can anyone advise what could be wrong ? Thanks in advance.

    Monday, May 1, 2017 9:07 PM

All replies

  • First question, does it eventually finish?

    Second question, how many virtual processors are there?

    A 'large' message would essentially be processed on a single thread so maybe 1 vp is at 100% and the rest are idle.

    What you're seeing isn't necessarily a problem, just an observation :).

    Monday, May 1, 2017 9:13 PM
  • Have you checked the performance counters for throttling?

    We have a virtualized Biztalk 2013 / MSSQL 2012 setup with both large and small messages and don't see problems like described

    rgds /Peter

    Tuesday, May 2, 2017 6:46 AM