Export (0) Print
Expand All

BizTalk RFID: Capacity Planning and Performance Tuning

This white paper provides implementation guidelines for Microsoft® BizTalk® RFID using data points in the various phases of implementation—planning, design and development, and post-deployment. It gives you ideas of the types of questions that you need to consider during implementation. You can use this white paper as a tool to help you successfully implement BizTalk RFID solutions.

Writer: BizTalk RFID Product Team

Published: December 2013

Original Publish Date: September 2007

Applies To: Microsoft BizTalk RFID in:

  • BizTalk Server 2013

  • BizTalk Server 2010

  • BizTalk Server 2009

  • BizTalk Server 2006 R2

Copyright

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

© 2007 Microsoft Corporation. All rights reserved.

Microsoft, BizTalk, Windows, and Windows Server are trademarks of the Microsoft group of companies.

All other trademarks are property of their respective owners.

Contents

Overview

The goal of this white paper is to provide guidelines for each phase in the BizTalk RFID life cycle (planning, design and development, and post-deployment). These phases are typically encountered in all BizTalk RFID implementations. Most of this white paper focuses on capacity planning and performance tuning tips for BizTalk RFID. In addition, this white paper provides guidelines for physical hardware and applications that run on a BizTalk RFID server.

In each of the sections of this white paper, the goal is to provide performance data and to illustrate the advantage of selecting one configuration over the other. The performance metrics shown in this white paper were obtained by running various test configurations on the Windows Server® 2003 platform using a default configuration and will yield higher results if additional tuning is applied.

Bb870305.note(en-US,BTS.10).gifNote
Currently, there is no industry standard performance benchmark to compare RFID systems.

Before looking at the capacity planning and performance tuning aspects described in this white paper, there are a few basic concepts to review. This section outlines the basic concepts required to understand the rest of this white paper.

Definitions

The following table defines terminology and acronyms that are used throughout this paper.

Term Definition

TPS

Tags per second

Input tag rate

Rate at which tag events are injected into the system. Input tag rate is measured in tags per second (TPS).

End-to-end latency

Time it takes to process an event from the moment the event is raised by the device until the last component in the pipeline is processed.

Throughput

Average number of RFID events processed per second (TPS) by BizTalk RFID.

Command response time

Total time it takes to send and receive a response from a command, from the application to BizTalk RFID to a provider to a device.

RFID process

A logical unit of execution that consists of pipelines of event handlers that process the events coming into the BizTalk RFID infrastructure. The process defines the business context in which the devices operate. A process can be defined independently of the deployment topology. In other words, a process does not have to be aware of the actual physical devices that the process binds to. A process contains logical devices, components (event handlers), and logical sources.

Logical source

A logical source contains a one or more logical devices and a set of event handlers. A logical source must be part of an RFID process.

N/A

Not applicable. Many of the tables used in this paper contain data elements that are not applicable to specific criteria. These elements are noted with "N/A."

Performance Data Flow

A performance data flow refers to operations in BizTalk RFID that affect performance of the overall system. Before reading this white paper, it is helpful to thoroughly understand the performance data flow that affects BizTalk RFID. The following figure shows the BizTalk RFID performance data flow.

Bb870305.f228002b-49e5-4ecb-bd1d-d17314517c12(en-US,BTS.10).gif

The major areas of performance data flow shown in the preceding figure are:

  1. Events are raised from a device to a provider to BizTalk RFID.

  2. Events flow through the process pipeline.

  3. Command responses flow from an application event handler to BizTalk RFID to a provider to a device.

Event Processing

This section builds upon the performance data flow in the preceding figure and shows how events are processed by BizTalk RFID. BizTalk RFID processes events in the following ways:

  • Event generation. Events are generated from an RFID device and are exposed to the platform by device providers. These events can be:

    • RFID operational events:

      TagReadEvent – Occurs when a tag is read.

      TagListEvent – Occurs when multiple TagReadEvent operations occur from a source.

      IOPortValueChangedEvent – Occurs when the I/O port value changes.

      VendorDefinedEvent – Occurs when a vendor-defined event is raised.

      Bb870305.note(en-US,BTS.10).gifNote
      All performance measurements in this white paper are associated with RFID operational events.

    • Management events

  • Device binding

    • If the device is not part of an active process pipeline, the events from the device will not be processed.

    • Depending on how the logical source is bound to a physical source, the events from one physical device may be delivered to a set of logical sources. For example, if a physical device is part of two logical devices in different process pipelines, such as "Shippping dock door" and "Verification portal", the event from the physical device will be delivered to both process pipelines.

  • Components in a pipeline. The impact of the components in a pipeline is not specifically related to the number of components, but instead depends on the following factors:

    • As events are processed in a pipeline, each component (event handler) that is part of the pipeline can handle specific events by implementing a method that handles a strongly typed message. For example, if an event handler implements a method to handle the IOPortValueChangedEvent event, then the event hander is invoked only when the specific event occurs.

    • Additional events generated as part of the pipeline.

    • The tag processing mode selected for an event handler. For more information about tag processing modes, see RFID Tag Processing Modes later in this white paper.

    • Depending on the operations a component performs and how it is written, there may be an effect on end-to-end latency and throughput of the system. For example, using a remote Microsoft SQL Server™ computer as the event sink will increase end-to-end latency and decrease throughput.

For more information about event handlers, see Design and Development Phase later in this white paper.

Command Response

When a command is issued to a provider, it sends a response after communicating with the device. The response time is dependent on these factors:

  • Whether there is an open connection to the device

  • The number of commands issued to the device

For more information about commands and responses, refer to BizTalk RFID help that is installed with BizTalk RFID.

Planning Phase

In this phase, you gather all the requirements that a system needs to satisfy and determine what equipment will be needed to satisfy those requirements. Usually the business owner and the IT administrator are involved in this phase.

Requirements

The first step in planning a BizTalk RFID implementation is to determine the requirements of the system. To determine these requirements, you need to ask several questions. While not an exhaustive list, some of the questions that you need to consider are:

  • What is the physical and network topology of the RFID software and hardware system?

  • What are the incoming tag rates? (Average, Peak)

  • Do you need high reliability and high availability for the server?

    Bb870305.note(en-US,BTS.10).gifNote
    The high availability feature is available only on Windows Server 2003.

  • What are your business processes that will require RFID data?

    • What is the typical workload split between event processing and use of the command response model?

    • Does your event processing require reliable storage or transactional semantics for the events?

  • What are your system performance requirements?

    • Throughput

    • End-to-end latency

RFID Equipment Layout

For capacity planning of specific hardware equipment, contact your independent hardware vendor (IHV). However, here are some general guidelines to consider:

  • What capabilities do you need from your RFID readers?

  • How many antennas can the devices support?

  • What are the read rates of the devices?

  • What are the guidelines for setting RFID device parameters?

Number of Devices Managed by a Node

When planning for your BizTalk RFID implementation, you need to consider the number of devices managed by a node. Some of the key aspects to keep in mind while determining the number of devices managed by a node are:

  • Latency for administrative operations will increase as you increase the number of devices in a node.

  • The number of events raised (data and management events) will increase as you increase the number of devices in a node.

  • BizTalk Server RFID Server supports up to 300 devices.

Workload Scenario

To help you determine the number of devices that are managed by a node, the performance metrics in the next section assume the following workload scenario:

  • The RFID process is bound to all devices by using a local sink event handler in the pipeline.

  • The StartProcess, StopProcess, and GetAllDeviceStatus administrative operations are tested. These three operations are ones that are most affected by the number of devices managed by a node.

  • The tests are performed with an in-process simulated device provider. Therefore, this workload scenario does not have any network calls to the device.

  • Administrative calls are invoked from the same computer as the the BizTalk RFID server.

Performance Metrics

The following table shows the performance metrics using the workload scenario described in the previous section. Configuration used is: 1.8 GHz, 2 GB RAM, single IDE hard disk.

Number of devices Administrative operation Response time - single processor (in seconds) Response time - dual processor (in seconds)

10

StartProcess

30.1

17.64

StopProcess

5.2

2.221

GetAllDeviceStatus

10.0

7.0

50

StartProcess

37.6

20.302

StopProcess

6.2

6.591

GetAllDeviceStatus

21.0

13.0

150

StartProcess

55.8

27.934

StopProcess

7.5

6.789

GetAllDeviceStatus

42.0

27.0

Summary

From the performance metrics shown in the preceding table, the following conclusions can be drawn:

  • Since the default time-out for the administrative operations specified in RFID Manager is 60 seconds, all the operations are expected to respond within this timeframe.

  • Response times of both StartProcess and StopProcess increase as the number of devices increases.

  • Response times significantly decrease when CPU power is increased by using an additional processor.

  • Because data is collected with an in-process simulated provider, it doesn’t include the network costs for opening a device connection. If an actual device is used, response times will likely be higher.

Design and Development Phase

In some situations, the design phase is separated from the development phase. However, for the purpose of capacity planning for BizTalk RFID, they are combined. In this combined phase, you design and develop how BizTalk RFID solutions will be implemented. This section is useful to solution architects and software developers.

RFID Tag Processing Modes

BizTalk RFID can process tags by using one of three tag processing modes that can be specified in RFID Manager:

  • Transactional – The pipeline processes each event in a transaction.

  • Reliable – Each event has a reliable store from where it is picked up and processed.

  • Express – No reliability semantics. The event is simply stored in memory and processed.

For more information about the tag processing modes, refer to the BizTalk RFID help.

Workload Scenario

To help you determine which tag processing mode to use, the performance metrics in the next section assume the following workload scenario:

  • A single RFID process pipeline is used.

  • A local SQL Server sink database is used.

  • Data is collected by varying the tag rates.

  • The tests are performed with an in-process simulated device provider. Therefore, this workload scenario does not have any network calls to the device.

Performance Metrics

The following table shows the performance metrics using the workload scenario described in the previous section.

End-to-end latency in this scenario is the elapsed time for the tag data to reach the sink event handler, but does not account for the time taken by SQL Server to insert data into the table.

Input rate (TPS) Server configuration Tag processing mode Throughput (TPS) Latency (ms) % processor time

100

Single processor
1.8 GHz
2 GB RAM
Single IDE disk

Express

100

110

37

Reliable

100

199

36

Transactional

100

534

77

200

Single processor
1.8 GHz
2 GB RAM
Single IDE disk

Express

200

96

45

Reliable

200

352

67

Transactional

N/A

N/A

N/A

300

Single processor
1.8 GHz
2 GB RAM
Single IDE disk

Express

300

77

65

Reliable

N/A

N/A

N/A

Transactional

N/A

N/A

N/A

200

Dual processor
3.0 GHz
2 GB RAM
Single SCSI disk

Express

200

~40

15

Reliable

200

~40

17

Transactional

200

147

50

900

Dual processor
3.0 GHz
2 GB RAM
Single SCSI disk

Express

900

~70

87

Reliable

900

~70

89

Transactional

NA

NA

NA

1200

Dual processor
3.0 GHz
2 GB RAM
Single SCSI disk

Express

1180

2000

90

Reliable

N/A

N/A

N/A

Transactional

N/A

N/A

N/A

Bb870305.note(en-US,BTS.10).gifNote
"N/A" in the preceding table indicates the input rate is too high to handle for the given scenario.

Summary

From the performance metrics shown in preceding table, the following conclusions can be drawn:

  • More tags can be processed with the Express tag processing mode than with the Reliable or Transactional tag processing modes.

  • The Reliable tag processing mode yields better performance than the Transactional tag processing mode. This mode has high throughput and a reliable store for events.

  • Throughput is significantly higher on a dual processor machine compared to a single processor machine.

  • The latency of Express mode and Reliable mode was found to be almost the same on the dual processor machine. This is likely due to having a SCSI drive.

RFID Process Design

When determining how to design your BizTalk RFID processes, you need to consider whether to use a single process with multiple logical sources or multiple processes. This section helps you to determine how to design your BizTalk RFID processes.

Workload Scenario

To help you determine how to design an RFID process, the performance metrics in the next section assume the following workload scenario:

  • The Express tag processing mode is used.

  • The scenario is four read stations, each having 25 devices.

  • Two separate designs are compared, as follows:

    • Single process – One process is used with four logical devices, each of which is bound to the devices in a particular read station. The tags are put into a SQL Server sink event handler. Each logical source has 25 devices. The pipelines use only the SQL Server sink event handler and all the pipelines use a single database.

    • Separate processes – Four processes are used. Each process has 25 devices. The pipelines use only the SQL Server sink event handler and all the pipelines use a single database.

Performance Metrics

The following table shows the performance metrics using the workload scenario described in the previous section.

Input rate (TPS) Server configuration Single process with logical sources Separate processes

300

Single processor
1.8 GHz
2 GB RAM

Memory (MB): 407

CPU busy %: 71

Memory (MB): 607

CPU busy %: 84

Summary

From the performance metrics shown in the preceding table, the following conclusions can be drawn:

  • Caching a device connection yields significant performance benefits. This needs to be done in scenarios where an application repeatedly accesses a device using the synchronous programming model.

  • The data was collected using simulated devices. When you use actual devices, expect the response times to be higher.

Device Connection Caching

A significant design consideration for your BizTalk RFID implementations is that of device connection caching. Caching a device connection means that a connection to an RFID device is kept open during processing. The connection is not opened and closed multiple times for a synchronous command operation. This technique could be used by an application that executes commands on a device. It could also be used by an event handler which, on an operational event such as IOPortChangedEvent, executes a command on a device. This section shows the benefits of caching device connections when performing frequent synchronous commands.

Caching a device connection must be done in code. The following C# code fragment shows how to cache a device connection:

private void Form1_Load(object sender, EventArgs e)
        {
            try
            {
                cachedConnection = new DeviceConnection(deviceName);
                cachedConnection.Open();
            }
            catch (Exception excp)
            { }
        }

       private void GetTags_Click(object sender, EventArgs e)
        {
            try
            {
                TagDataSelector tagSelector = TagDataSelector.All;
                ICollection<TagReadEvent> listOfTags = cachedConnection.GetTags(tagSelector);
            }
            catch (Exception excp)
            { }
        }

            //In the Dispose method, close the connection:
            if (cachedConnection != null)
            {
                try
                {
                    cachedConnection.Close();
                }
                catch (Exception excp)
                { }
            }
Bb870305.note(en-US,BTS.10).gifNote
If the device connection is not closed properly, the device will continue to be in the "Open" state even after the application is closed.

Workload Scenario

To help you determine whether to use device connection caching, the performance metrics in the next section assume the following workload scenario:

  • A single device is used.

  • One process is bound to one device.

  • The process uses the SQL Server sink event handler.

  • Each synchronous command is executed ten times and the response time is averaged.

  • Machine configuration uses a single processor running at 1.8 GHz, and 2 GB of memory.

  • The tests are performed with an in-process simulated device provider. Therefore, this workload scenario does not have any network calls to the device.

Performance Metrics

The following table shows the performance metrics using the workload scenario described in the previous section.

Synchronous command Average response time (device opened/closed) Average response time (device connection cached)

GetProperty

402

23

SetProperty

420

39

GetTags

473

84

PrintTag

411

23

Summary

From the performance metrics shown in the preceding table, the following conclusions can be drawn:

  • Caching a device connection yields significant performance benefits. This needs to be done in scenarios where an application repeatedly accesses a device using the synchronous programming model.

  • The data was collected using simulated devices. When you use actual devices, expect the response times to be higher.

Post-Deployment Phase

The post-deployment phase is the part of a BizTalk RFID implementation life cycle that occurs after the solution is deployed into production. The post-deployment phase contains tasks that are ongoing, instead of being one-time tasks.

This section discusses the performance monitoring and troubleshooting aspects of a BizTalk RFID implementation. Unless otherwise mentioned, Windows® Performance Monitor (also referred to as "Perfmon") is the primary monitoring tool. This white paper provides code fragments to assist you in monitoring BizTalk RFID solutions.

Performance Monitoring

Performance monitoring refers to viewing and analyzing specific data points called counters. A counter measures a specific metric associated with a BizTalk RFID operation. Microsoft Operations Manager (MOM) has performance rules that use these performance counters so you can use MOM to alert you based on criteria set for these counters.

Category Counter Description

RFID:Process

Tags In Queue

Represents the total number of tags that are currently queued up for processingi

RFID:Process

Tags Processed

Represents the total number of tags that have been processed by this process

RFID:Process

Tags Being Processed

Represents the number of tags that are currently being processed in the process pipeline(s)

RFID:Process

Tags Suspended

Represents the number of tags that have been sent to the suspended queue (tags that caused failures)

RFID:Process

Process Uptime

Amount of time that has elapsed

RFID:Devices

Total Tags Read

Total number of tags received from the device instance

RFID:Devices

Tags Read/sec

Rate of tags being received from the device instance

RFID:Devices

Total Tags Written

Total number of tags written from the device instance

RFID:Devices

Tags Written/sec

Rate of tags being written from the device instance

RFID:Devices

# of Errors raised

Number of errors raised by the device

RFID:Devices

# of Errors raised / sec

Rate at which errors are raised from the device

RFID:Devices

Downtime

Duration for which the device has been down after a connection error

For more information about using Perfmon, see the BizTalk RFID help topic, "How to Monitor BizTalk RFID Using Performance Counters."

Bb870305.note(en-US,BTS.10).gifNote
At times, the names of the performance counters shown in the preceding table may be misleading. These counters track the number of events raised from the provider and not the number of tags. For example, the counter Total Tags Read tracks the events such as TagListEvent, TagReadEvent, and IOPortValueChangedEvent raised by the provider. Therefore, a TagList containing 10 TagReadEvent events will increment the counter only once.

General Guidelines

This section provides some general guidelines for how to monitor the performance of a BizTalk RFID implementation. In all cases, we recommend that you monitor performance by using the following approach:

  • Measure the performance after the system is in a steady state.

  • Because many system factors can affect performance at any one time, all testing and monitoring should be performed multiple times. The response metrics should be averaged to determine overall performance.

Measuring Throughput

Using C# code fragments, this section shows how to measure throughput of a BizTalk RFID installation programmatically in the following ways:

  • Retrieving the number of tags processed by a process:

    System.Diagnostics.PerformanceCounter tagsProcessedCounter 
    = new PerformanceCounter("RFID:Processes", "Tags Processed", "TestProcess"/*Process name*/);
    int noOfTagsProcessed = (int)tagsProcessedCounter.NextValue();
    
  • Retrieving the number of tags read by a device:

    PerformanceCounter deviceTagsRead 
    = new PerformanceCounter("RFID:Devices", "Total Tags Read",
     "device0" /*device name*/);
    int noOfTagsRead = (int) deviceTagsRead.NextValue();
    
    
  • Retrieving the number of tags read by all the devices:

    PerformanceCounter deviceTotalTagRead 
    = new PerformanceCounter("RFID:Devices", "Total Tags Read", "_total");
    int noOfTagsRead = (int) deviceTotalTagRead.NextValue();
    
    

The following logic can be used to calculate the throughput and the input tag rate for a set of processes, each bound with a different set of devices. In this example, t1 is the start time of the test and t2 is the end time of the test.

  1. Calculate the total of the initial tags processed by each process at the time of t1. (initTagsProcessed)

  2. Calculate the initial number of tags read by all the devices at the time of t1. (initTagsRead)

  3. Allow the business activities to happen for a period of more than 30 minutes.

  4. Calculate the total of the final tags processed by each process at the time of t2. (finalTagsProcessed)

  5. Calculate the final number of tags read by all the devices at the time of t2. (finalTagsRead)

  6. Throughput and input tag rate can be calculated with this C# fragment:

    long avgTagsProcessed = ((finalTagsProcessed - initTagsProcessed) / noOfProcesses);
       TimeSpan ts = t2.Subtract(t1);
       long timeDiff = ts.Days * 86400 + ts.Hours * 3600 + ts.Minutes * 60
                       + ts.Seconds;
       throughput = (int)(avgTagsProcessed / timeDiff);
       inputTagRate = (int)((finalTagsRead - initTagsRead) / timeDiff);
    

Measuring Process Pipeline Overall End-To-End Latency

To measure the end-to-end latency in a process pipeline, you can implement a timer-based event handler. This event handler can then be placed anywhere in the pipeline. Typically, this event handler should be the last component in the pipeline. This will enable you to measure the complete end-to-end latency in the pipeline. The event handler can add a vendor-defined key, named Latency, to the event. The vendor-defined key can be added and computed by using this C# code fragment:

[RfidEventHandlerMethod]
        public TagReadEvent ProcessTagReadEvent(
            TagReadEvent tagReadEvent)
        {
            TimeSpan e2eLatency = DateTime.Now - tagReadEvent.Time;
            tagReadEvent.VendorSpecificData["E2ELATENCY"] = e2eLatency;

            return tagReadEvent;
        }

Measuring Process Pipeline SQL Server Sink End-To-End Latency

The end-to-end latency can also be measured by using a SQL query in the SQL Server sink event handler database. The SQL Server sink event handler comes with BizTalk RFID.

The following SQL query calculates the difference between the TagTime and SinkTime columns, which are automatically recorded by the SQL Server sink event handler:

SELECT AVG(DATEDIFF(ms, TagTime, SinkTime)) FROM TagEvents

Measuring Command Response Time

The response time for a command can be computed by the difference in system time before and after the command is executed. To measure the response time of a specific command, you can use the following methodology:

  1. Mark the start time (t1).

  2. Execute the command successfully.

  3. Mark the end time (t2).

  4. Find the difference between t2 and t1.

  5. Repeat the preceding steps at least 10 times and average the difference between t2 and t1.

Performance Troubleshooting

To help troubleshoot performance problems with your BizTalk RFID installation, begin by searching for the troubleshooting topics in the BizTalk RFID help. Additional troubleshooting tips are shown below.

Event Processing Stalls and System Throughput Worsens

Monitor the value of the RFID:Process – Tags in Queue performance counter and check if the counter value is increasing over time. If so, this indicates that the system is not able to sustain the input tag rate. Refer to the section Design and Development Phase earlier in this white paper. One possible solution is to modify the tag processing mode.

System Stalls and Spawns Several Threads

BizTalk RFID uses the thread pool extensively while processing events. If the event handler needs threads from the thread pool, there may be contention with the server itself for the same threads. Event handlers should consider increasing the thread pool size if they need to use threads from the thread pool (either directly or indirectly).

High Response Times for Device Operations

If your system encounters high response times for device operations, consider device connection caching for repetitive synchronous operations. More information about device connection caching can be found in the Device Connection Caching section earlier in this white paper.

High End-to-End Event Processing Latency

Here are some tips for troubleshooting high latency when processing events:

  • Make sure the device and host are in the same time zone.

  • In cases of remote SQL servers, make sure the device and the SQL server are in the same time zone.

Conclusion

This white paper provided guidelines using data points in the various phases of implementing a BizTalk RFID solution—planning, design and development, and post-deployment. Some sections showcased the advantages of using a particular configuration over another. All the tests used to generate metrics in this white paper used device simulators and did not measure the network latency. In real-world scenarios, additional latency from the device or network will affect the numbers. Additional tuning on a production system can boost the overall system performance.

In summary, you need to use this white paper in conjunction with your business scenarios to implement a system that performs well.

For more information: http://go.microsoft.com/fwlink/?LinkID=93454

Did this paper help you? Please give us your feedback. On a scale of 1 (poor) to 5 (excellent), how would you rate this paper?

Show:
© 2014 Microsoft