The purge rule defines how real-time data is stored in system memory. Tracking Analyst stores real-time data completely in memory to maximize performance. To limit the amount of memory consumed, real-time data must occasionally be removed, or purged, from the system memory.
The purge rule is the mechanism provided in Tracking Analyst for specifying how much data is removed from memory for a real-time tracking service and how often. A purge rule is defined individually for each tracking service. Generally, there are two purge rules to choose from: Purge Oldest Records and Purge All Except Latest.
Choosing the right purge rule for your real-time tracking service is critical for maximizing functionality and performance.
Auto purge and purge threshold
The Auto Purge option on the Tracking Service Properties dialog box controls whether or not purging occurs at all. The purge threshold is the number of records that must be stored in memory before Tracking Analyst purges data. In most situations, you want to enable the Auto Purge option. When auto purge is disabled, data will never be purged from memory, and the consumption of memory will continuously increase. This can be used successfully only if you know you have a slow data feed that is not going to consume much memory. Another situation when you might want to disable the Auto Purge option is while you are making changes to the purge settings. By disabling automatic purging, you can observe how fast your data grows and judge how large you need to set the purge threshold.
Purge oldest records
The Purge Oldest Records rule is useful when you want to display some history for your tracked objects. When using the Purge Oldest Records rule, the oldest records are deleted from the geodatabase according to their time stamps. There are two parameters that determine when data is purged—the purge threshold (total number of records stored in memory) and percentage of data to purge when the threshold is reached.
The threshold is the maximum number of features allowed to be stored in memory. When this limit is reached, a purge is triggered. Purging removes the number of records specified by the Percent to Purge parameter. For example, imagine that the Threshold parameter is set to 10,000 and the Percent to Purge parameter is set to 20. As soon as the total record count in memory reaches 10,000, a purge will occur that will delete the oldest 2,000 records.
Purge all except the latest
The Purge All Except Latest rule is useful for situations when you are tracking many entities and you are only concerned with their most current position and attributes. For example, if you are tracking a fleet of delivery vehicles, you might only want to know the current position of each vehicle. Monitoring a sensor network is another case where the Purge All Except Latest rule might make sense. Since some sensors only generate messages when there is a state change, sensors that detect a lot of activity could consume a lot of memory and cause data from less active sensors to be purged from the database if you were using the Purge Oldest Records rule. Using the Purge All Except Latest setting would solve this problem.
The Purge All Except Latest setting is intended for use with continuous observations that have a Track ID defined. As data is streaming in, events are grouped into tracks based on their Track ID. The Purge All Except Latest setting causes the previous observation for each track to be deleted as soon as a new observation is received. This is useful if you only want to see the current location and attributes of each different tracked object.
The same visualization can be attained using the Purge Oldest Records setting and symbolizing only the most current events. However, this can be risky, because it is possible for entire tracks to be purged from memory if their most recent observation happens to be in the oldest set of records.