Performance Considerations

When implementing TagNet especially in a large scale deployment, understanding system overhead is something to be aware of as it can affect the functioning of the system. Initial sizing of the Server is meant as a starting point and CPU resources need to be evaluated as the deployment grows in tag volume as well as business rule complexity.

 

 

Database Usage

The first and most important consideration is to make sure the Application and Database Servers are sized for how TagNet is being used. If using a shared SQL instance and there are other databases being accessed, these can take away from the CPU cycles that TagNet needs. The best approach is to have TagNet on a dedicated SQL instance to avoid this type of contention. Refer to server sizing information from the support site.

Running expensive SQL queries on the TagNet database during production hours can have a ranging effect on overall system performance. This can slow down the time it takes to render a TagNet web page all the way to how long a user has to wait for a read event to visualize. Ongoing data retrievals for BI tools should be offloaded to another DB server if they consume excessive resources.

Features to Manage System Overhead:

1.Session State defines the duration of time and conditions that an inventoried tag remains in either of two 'states (A or B) as defined by the tag's chipset and more info can be found in this section. If you have many tags that dwell in front of antennas unnecessarily, TagNet is constantly processing them to see whether they are applicable for another inventory state change. This can be exacerbated if your read cycle duration is very short. 

Consider using S1 at a minimum or S2 for loitering tags. When the tag is in 'B' state it stops the event at the source whereas the tag will not respond to the reader... in other words the tag is saying  'I am not ready to be inventoried'. This is the most effective method to reduce overall system overhead.

When should I not use Session State?  If you have read stations whereas an operator can pickup a tagged part at any time and present to an antenna for AutoID purposes (and represent at any time), using session states should be carefully considered. Some tags when in S1 won't respond for a few seconds where as S2 can be up to 60 seconds after it leaves the RF field! This can cause confusion with operators thinking the system is 'not working'.

2.Tag Filtering feature is explained here and will only include those TagID prefixes that you specify. The filtering takes place at the server level so it will continue to take up bandwidth and server side resources.

For example: if your TagID prefixes start with 'A1' or 'BA1', 'BA2', etc. you can put in Prefixes such as 'A1,BA',

This feature becomes important if your facility is seeing a lot of tags from 'other' sources such as vendor packaging. Note that UHF RFID is used worldwide and quite often material is purchased with supplier tags that will show up in your TagNet logging. Although they will show as 'unmapped' they can still take bandwidth and server time to process unless filtered out.

3.Net Change feature is explained here and will stop all logging and evaluation for inventory moves if the tag is still being seen at the same reader/antenna. This certainly will reduce overhead with respect to database logging however the read event still needs to be evaluated to determine this. Network traffic is still going on as well as CPU cycles to evaluate albeit not as much if the Net Change feature was not enabled.

Consider using Net Change at any read point once it has been processed and doesn't turn around and pass through the same read point (e.g. a paint line). This is another effective method to reduce overall system overhead.

4.Dwell feature is explained here and will prevent an inventory state change until the dwell expires. This does not stop base logging nor network usage as it is implemented at the Binding level (so the feature can be customized for the use case). This will reduce overhead with respect to the same tag being evaluated and moved unnecessarily.

The most typical reason to use this feature is when managing directionality at a single choke point.

5.Event Viewer is a powerful tool to visualize (resolved) tags in real-time however this does come at a cost if there are may EV clients accepting those events. This does consume both Server resources as well as network bandwidth.

Limit those number of users/browsers with the EV active if not required, TagNet has to broadcast these events to each and every browser session that has the EV URL called up.

Don't leave EV sessions linger when not in use as they are still consuming server resources. Additionally if the EV [clear] setting is not used the browser cache can fill up and slow down the browser and desktop.

When reading large amounts of tags (e.g. 50+) with a short read cycle (e.g. < 5 secs) there can be a noticeable delay to resolve those and visualize in the EV. This can cause confusion when trying to test read events in real-time.

6.Tag ID Limit feature is explained here and will prevent a given TagID from being read more that 'X' times as defined at the reader level. Once a tag has reach its daily count limit it will be ignored for further logging or business events however network usage will still occur. This will reduce overhead with respect to the same tag being evaluated and moved unnecessarily.

Consider implementing this feature where tagged material is loitering around read points where the previous features mentioned above cannot be implemented because of the use case. Consider an AutoID station that has a (1) second read cycle and a cart of (40) parts that are brought too close, and this constant scanning occurs after hours until the next working day. This can result in tens of thousands of read events being logged and/or evaluated for IMOVE.

 

 

Copyright © 2024 Stratum Global, Inc.