BizTalk 2010 WCF-BasicHTTP SendPort takes a long time

Question

I have an orchestration that calls a WCF service using a two way WCF-BasicHttp send port. For test purposes my WCF service just takes a parameter, and returns a value so I know it doesn't have any time consuming logic. In fact with the WCFTestClient client tool I know the WCF service call takes only a few milliseconds.

When I call the WCF service in my orchestration the send shape takes roughly 7 seconds or so, and the receive shape takes about the same. So time spent in my orchestration for example could be 15 seconds and the send and receive shape for the wcf service takes over 90 of that.

The only thing I could think of was that the polling settings on my hosts were out of whack. I have 3 hosts, 1 for send ports, 1 for receive ports and one for orchestrations. Each is configured with the default configuration.

Further, my open, send and close timeout settings for the send port are 5,4, and 3 seconds respectively. Neither operation is timing out, and I am convinced the issue is not in the wcf service itself, it's in BizTalk or my BizTalk solution.

In the images below, notice the sndGetDemographics and recGetDemographicsResponse each take around 7 seconds to complete:

Answer 1

Seems to me your pipelines are to blame. If you are using XMLTransmit/XMLReceive, try moving towards PassThruTransmit & PassThruReceive pipelines.

It looks to me that way because the Receive event of the send port is perfect in respect to timing, only the Send event takes ages.

Just to be sure: you're not using any special WCF behaviors/inspectors?

Answer 2

I discovered my problem. Because various other components were writing fairly verbosely to the event log I did not notice this before, but it appears BizTalk was throttling some of my host instances (I have 3, one for receiving, one for sending, and one for orchestrations) as a side affect of something else.

What happen was, for test purposes, I had a send port using a file adaptor, outputting my received messages to a directory. As the amount of files grew, the file system became very sluggish, causing the send port instances to take a very long time, and suspend in some cases. This caused the message box to grow. BizTalk saw the growth and decided to throttle the host instance so that it would publish messages at a slower rate, which explains why the send and receive shapes for the wcf service call was taking a long time.

I learned a fair amount about BizTalk throttling in this lesson! Additionally, be very careful and contentious about using the file adaptor on a send port.