Home > BizTalk Server > BizTalk 2006 Performance

BizTalk 2006 Performance

At work we have a BizTalk farm consisting of 2 servers, both of which are relatively fast (they have dual processors with dual-cores). The various BizTalk SQL Server databases sit on an even faster server with 4 processors, each with a dual-core. The databases are clustered to provide fail-over. Okay, great. So why I am sharing all this…

We started having performance problems at work. The production load was not all that great, and the servers were basically idling. I was quite disappointed when BizTalk, the service I manage, took the blame for ERP performance issues (SAP interfaces with the rest of the company by sending out messages from XI to BizTalk, who then fans out messages to all other downstream systems… when XI could not deliver messages to BizTalk fast enough, a backlog started building up until all XI communications came to a halt). So what did I do?  A few things…

First,  someone on the XI team pointed out that if I tried to visit the WSDL of the service sitting on the BizTalk box it took a very long time to open.  Based on this, I then looked at how things were set up in IIS (run ‘inetmgr’ command) and found that the 5 or 6 web services being called from XI were all sharing a single application pool, with the “web garden” setting set to 1.  Apparently, if not set otherwise.  I added new application pools, one for each web service and then also bumped up the “web garden” setting to 5 (# of processors + 1).

Web Garden Setting in IIS

Once the heyday of directors arguing over what to do next subsided and someone accidentally turned the XI interface on again without permission (whoops!), the problem of getting messages into BizTalk from XI immediately went away.  I thought my problems were solved, but then soon found out that many of the downstream subscribers weren’t getting messages!  I checked and sure enough, there were lots and lots of messages queued up, although “Active”, for each downstream system.  I then looked into throttling.

Like most of us out there, I started to read the manuals when trouble started (and too often not before then, unfortunately). The first “manual” to read in my opinion so far as I am concerned is Professional BizTalk Server 2006. After reading on throttling and finding the MSDN site on Host Throttling Performance Counters (which describes things well), I found that we hadn’t made all of the registry changes we had started (and planned in the beginning) as new hosts were added to the system.  Pages 460-461 of Jefford’s book describes those registry settings.  I made those changes and then took a look at throttling again.  The system was still throttling, in State 6, which is due to database size (basically after fixing the IIS settings I was now getting messages in faster than I could send them out).  I couldn’t believe it – here the server is idling and yet we’re throttling.  I added a counter on database size and found that the database was huge and that this accounted for the throttling.

Database Size

So I changed this:

Throttling Thresholds

I found that I had to bounce the host instance for the change to take effect, but once I did that it worked like a charm.  This particular throttling setting is kind of funny because you’d think that if you’re database size is growing too fast you’d want NOT to throttle (so the messages could get out and have the size go down), right?  Well, I guess someone thought otherwise (probably someone who thought about this a lot more than me, I might add).  Nonetheless, in my situation, this is exactly what I needed – to stop throttling.

Categories: BizTalk Server
  1. June 25, 2008 at 10:59 pm

    Hi Victor,
    Did you check on the Spool size, application host queue, service class instances and the number of instances each service class could handle. I know I’m pointing out to alot, but when you mentioned the database size – I couldn’t resist 🙂

    I’ve done a performance blog on BizTalk (now I’m marketing 🙂 ) .. check it out if heads out some good pointers..


  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: