BizTalk Testing - Part 1: Generating Load

Why does everyone (or is it just me) refer to this tool as "BizTalk" LoadGen?  There is nothing BizTalk-ish about it.  Your right, its not a part of BizTalk, but all applications of it seem to be associated with BizTalk.  Why is that?   You've spent months devising plans on how to take over the world using BizTalk, but hey, guess what?  If no one pokes your BizTalk implementation with a stick (external stimuli, aka message) what does your implementation do?  Nothing.  BizTalk can be an insatiable, slathering beast when it comes to message consumption, but if your not feeding it, it will slumber away in the darkness waiting for that sharp poke.

Lets pretend that your organization integrates Item lifecycle events (add, update, retire) to several different applications throughout enterprise  You've built all of your integration architecture on top of BizTalk and now your ready to test those BizTalk artifacts.   Unfortunately, the application that sources these events to your messaging bus is unable to be used to generate the load for your testing.  This used to mean you had to go write some sort of test harness that could now generate that load for you. 

I've seen quite a few simple (but slick!) methods of generating this load.  Some of these methods are:

• The Grass Roots Method: Having a file directory full of the data files that will be copied to a File receive location, using a batch file (or vbscript, jscript, etc) that is scheduled to execute using Windows Task Scheduler.
• The Roll Your Own Method: Writing custom code (test harness) to do the file copies, similar to above, but using code.  Maybe here threading has been introduced to have multiple threads doing copies.  We probably also had the need to push data using multiple protocols (MSMQ, HTTP, etc).  Of course, now we've introduced complexity that we shouldn't be spending time on (but can be fun nonetheless). 
• The Complete Package:  a full blown automated testing solution such as Silk Performer, LoadRunner, or Microsoft Team Edition for Software Testers.  Now, unless your development staff cross trains as Test Engineers, or you have them available, this can be even more complex.

These testing solutions will all work to varying degrees.  However, you may  need to consider a 4th method, that sits between the Roll Your Own Method and the Complete Package:

•  The Pareto Method: Microsoft's free LoadGen.  It is more robust than the Grass Roots Method, removes most of the need for maintaining an often buggy Roll Your Own Method, and is much less expensive than a Complete Package.  With a fresh install, will cover 80% of what you probably need to do when testing some basic application protocols: File, HTTP, MSMQ, Soap, WSE.  The key is all the dirty details of controlling arrival rates is taken care of for you in the core product.  You can also extend the tool if necessary in some very key areas, namely Transport, Message Creation and Monitoring.  There is only minimal documentation, so if you need to figure out how to write a new Transport for LoadGen, fire up Reflector and you'll be writing the transport for tcp/ip, JMS, or whatever, else you might need. 

 

Real World Example

Lets take another look at our Item integration briefly described above.  Given that one Item looks much like another at the messaging layer and we are only interested in the load placed upon the system, then we could conceivably replace the source system with LoadGen.  We would need a single instance of an Item message for LoadGen to work with, but then we could have it generate as many messages as we want to test with.  It will be repeatable and we won't have a dependency on the source application. 

A specific test case that we needed to execute recently was generating 30K of these Item messages that would be sent across our WAN to a remote data center.  We had the primary goal of monitoring the impact of the messages on the network, but a secondary goal of monitoring our BizTalk implementation.  In this case, the load agent was a machine running LoadGen publishing Item messages to a local BizTalk server group.  BizTalk then sent the messages across the WAN to a web service gateway in a remote data center.  There is another BizTalk server group waiting to broker those messages in the remote data center, but for the purposes of our current test, we are done. 

In the grand scheme of things, 30K messages flowing through BizTalk is nothing (ok, depends on your infrastructure backing your solution), however, as with anything but the most simple BizTalk implementation, there are many moving parts (Pipeline Components, Functoids, Orchestrations, Custom Libraries) that you will want to see under load.  LoadGen allows you the opportunity to monitor your solutions (application and infrastructure), under a variety of loads, without having source systems available.  This means you can be more proactive (vs. reactive) in identifying those bottlenecks, and other problems, before you've got other team members waiting on you.  Is the view 100% completely accurate with how it will behave under 'true' production loads?  No.  But, you may be surprised at how far that 80% will get you.