When developing applications, at some point in the dev cycle we want to know how the system will perform under load. In BizTalk RFID land it is no different. In fact, in BizTalk RFID implementations we often deal with devices capable of raising hundreds of reads every second. So how do we go about testing these?

I'm a big fan of using physical devices during development rather than device emulation, but when it comes to load testing we need to present hundreds of tags to the reader and no matter what I try I just can't get the work experience kid to act fast enough! But instead of using a emulated device, what if we could raise tag read events programmatically and have our RFID Process consume them? Surely then we could get enough events to constitute a decent load test.

So how do we go about pushing tag read events through our RFID process in code?

We do this using the BizTalk RFID management API's, namely the ProcessManagerProxy. In just a few lines of code we can connect to the RFID process we want to test and "submit" a tag read event to the event pipeline. To get up and running with this you will need to add the following references to your project: (all can be found in %RFIDINSTALLDIR%\bin)

• Microsoft.Rfid.Design.dll
• Microsoft.Rfid.ManagementWebServiceProxies.dll
• Microsoft.Rfid.SpiSdk.dll
• Microsoft.Rfid.Util.dll

Then, in three lines of code you can create your tag read event, connect to your process, and submit your event for processing;

// Create the tag read event to submit
TagReadEvent tag = new TagReadEvent(  HexUtilities.HexDecode(strTagID), 
                                      TagType.EpcClass1Gen2, 
                                      HexUtilities.HexDecode(strTagData), 
                                      strTagSource,
                                      DateTime.Now, null, null );
                                                                     
// Connect to the local RFID server
ProcessManagerProxy proxy = new ProcessManagerProxy("localhost");

// Submit event to the event pipeline
proxy.AddEventToProcessPipeline( strRfidProcessName, tag, strLogicalDeviceName);

And that's it.

For my needs, I created a quick Win forms app that retrieved a list of registered tag id's from a SQL DB and submitted them to my RFID process at configured intervals:

I added a few variables to adjust the interval between tag read events, the number of events to submit each interval, and the number of duplicates to send for each tag id. These variables (used when looping through the set of tag id's) combine to give me a good approximation to a real, high volume environment.

Firing up good old perfmon and adding the RFID:Process counters, I ran through a number of test configurations to make sure my RFID process performs well under high load. (Note: the RFID process you are monitoring must be running before you can add the counters). Of most interest is the Tags In Queue counter. This tells me when my process is not performing well and tags are being queued up waiting to be processed (not good in real-time processing systems). We want this to be flat-lined most of the time.

Another good idea is to use the SQL Sink EH component while testing. After running your tests you can simply and easily calculate event processing latency by executing the following T-SQL query against the tagevents table in the RfidSink DB.

SELECT AVG(DATEDIFF(ms, sinktime, tagtime)) FROM tagevents;

A while back, Mick posted about a great article on MSDN around performance and capacity planning for BizTalk RFID. Some goodness in that article so check it out as well.