Got the chance to spend a bit of time on the recently released BizTalk Server 2004 Load Generation (LoadGen) tool that we made available. Fairly useful, if not entirely intuitive, tool for blasting out lots of content.
So before diving into some screenshots, a quick summary of the LoadGen bits. The goal of this bad-boy is to enable the quick and dirty generation of content to be processed by any of the inbound BizTalk Server 2004 adapters. So, easy way to swap out adapters, and still pummel your system with data to check how you effectively handle load. The primary components are:
- Core Framework. This is where messages are created and your self-defined configurations are interpreted.
- Load Generation Runtime Executable. The two means of executing the loadgen process, via a Console UI or the command line.
- Load Generators. These guys are in charge of taking the messages and sending them to the chosen interface protocol. Examples include HTTP, File, FTP, POP3, SOAP, MSMQ, MQSeries and WSE.
- Throttling Controller. This pretty much monitors and controls the rate of input.
- Message Creation. So you have the standard choice of just pumping the same file over and over through the tool, or alternately using Message Creation, dynamically generate either unique or random data. Good way to test processes that require correlation.
Ok, so my first run through was with the FILE adapter. I chose to just continually pump the same data through just so that I could monitor standard performance. As you see in the screenshot below, I can choose the lot size to generate on each pass, how much time between each pass, and of course, where to drop the files to be picked up by BizTalk.
See below that if I test the HTTP adapter, I can choose to also write out a (.csv) report outlining latency in my HTTP calls. Good times.
Notice that the SOAP transport provides the ability to set the SOAP header. As with HTTP, you can also specify a directory for the response message.
Finally, for MSMQ, check out the ability to specify the server (or cluster) for queuing.
When you run the test, the graphical UI looks like this. It’s a bit rough, but it gets the point across.
So, what’s the result of this? Well, you’ll want to be tracking how your system responds to the load. Below is my Performance window where I’ve got a few counters up that interest me. I’m recording Documents Received/Sec, Orchestrations Completed/Sec, Running Orchestrations, and Persistence Points/Sec. As you would expect, I’m receive-heavy up front, then the orchestrations kick in. And, there are, naturally, more persistence points than orchestrations. I like watching persistence points because being aware of the database traffic BizTalk creates can often change how you build your orchestrations to minimize persistence points.
All in all, neat stuff. Don’t rely to heavily on included documentation, as there isn’t a whole lot. But, there’s enough samples for you smart folks to do some damage. Any other tools that are in your standard perf-test toolbox?