1

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: Orchestration Times

Relevant orchestration shapes

Jeremy
  • 44,950
  • 68
  • 206
  • 332
  • Perhaps database access issue when accessing its message box. I'm trying to examine the BizTalkMsgBoxDb database a bit on my end. Maybe you have a table with a lot of entries or index problems. I'll post as answer if I find something more precise. – Francis Ducharme Dec 10 '13 at 19:13
  • 1
    Can you run an SQL query to get the table sizes in BizTalkMsgBoxDb and see if one is abnormally big ? http://stackoverflow.com/questions/7892334/get-size-of-all-tables-in-database – Francis Ducharme Dec 10 '13 at 19:20
  • Could you try and place a second send/rec to the same service straight after the first in the orchestration. If this runs significantly faster it may be there is some initialisation cost somewhere? – Jason Hyland Dec 10 '13 at 20:17
  • I can't see the graphics where I am but I will point out that the shape times are not always accurate. To confirm, keep a timer and write an Event Log entry or something similar. Also, is this every time, not just the first? – Johns-305 Dec 10 '13 at 20:32
  • @Jason Hyland - I don't think it was initialization costs because this happened on every instance. – Jeremy Dec 17 '13 at 23:19

2 Answers2

1

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.

Jeremy
  • 44,950
  • 68
  • 206
  • 332
0

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?

zurebe-pieter
  • 3,246
  • 21
  • 38