PItoPI Interface: Workload Distribution, Scan Classes, and Performance Tuning

The OSIsoft PItoPI Interface is a popular solution for transferring data between PI Data Archives. A common performance optimization question is whether distributing tags across multiple scan classes (with the same frequency) can help reduce the workload on the PItoPI interface, especially when handling thousands of tags in exception collection mode. Let's unpack this scenario and provide clear guidance on efficiently optimizing your PItoPI interface.

Scan Classes in PItoPI: Polling vs. Exception Collection

Polling Interfaces (e.g., OPC): For conventional polling interfaces, scan classes define how often tags are polled from the data source. Distributing tags across multiple scan classes (with suitable offsets) helps in load leveling and can prevent overload, as each scan class operates on a schedule and manages a separate processing queue.

PItoPI in Exception Mode: When operating in exception collection mode—a common configuration for PItoPI interfaces—the behavior is fundamentally different. Here’s why:

• PItoPI subscribes to updates on the source PI Data Archive via the PI Update Manager.
• Updates are pushed to the interface on an exception basis, not on a regular polling interval.
• The interface retrieves available updates from the Update Manager on a schedule defined by the scan class frequency.

Key Point:

Creating multiple scan classes with the same frequency under exception collection does not distribute workload or offer performance benefits. All scan classes with the same frequency execute at the same time, and the core data queuing is managed centrally by the Update Manager, not by the scan class mechanics.

---

The Real Bottleneck: PI Update Manager

The Update Manager on the source PI server holds events in memory until the PItoPI interface retrieves them. If the interface doesn't keep up, the Update Manager's queue grows, which can stress server memory and eventually impact data delivery.

Critical configuration parameters:

• MaxUpdateQueue: Maximum number of events per point in memory.
• TotalUpdateQueue: Global cap for events across all points.

Increasing these can help if the Update Manager is the bottleneck, but be cautious—higher values can consume significant RAM.

---

Performance Solutions

1. Multiple PItoPI Instances
Rather than slicing tags into different scan classes, consider running multiple instances of the PItoPI interface. Each instance independently signs up for updates and can read from the Update Manager concurrently, improving throughput and reducing the risk of a single bottleneck.

2. Scan Frequency Tuning
Faster scan classes reduce the latency between source and target servers (i.e., how quickly updates are transferred). However, setting every scan class to 1 second is rarely needed for all tags—consider the actual update rate and importance of the signals. Critical/alarm tags may warrant rapid collection; for less time-sensitive data, a slower scan rate is often sufficient.

3. Update Manager Tuning
If bottlenecks persist and cannot be solved by multiple PItoPI instances, carefully tune MaxUpdateQueue and TotalUpdateQueue. Monitor memory usage on the source PI server before, during, and after to avoid over-committing resources.

---

Exception vs. Polling – Understand Your Interface

Unlike polling interfaces, PItoPI (in exception mode) is fundamentally tied to the way PI Data Archive manages snapshot updates. Trying to balance load by manipulating scan classes doesn't have the same effect as with OPC, DNP3, or Modbus interfaces.

If you need true parallel processing, scale out with multiple interface instances, not scan classes.

---

Architectural Considerations

• Interface Placement: Locating the PItoPI interface on or near the target PI Data Archive (pull model) generally minimizes network latency.
• Buffering: For push configurations across slow or unreliable networks, enable PI Buffer Subsystem to mitigate network interruptions or latency.

---

Quick Tips

• Distribute tags across scan classes for polling interfaces, not for PItoPI in exception mode.
• Use multiple PItoPI interface instances for higher throughput needs.
• Tune Update Manager queues with caution; always monitor RAM usage.
• Match scan frequency to business requirements, not just data update rates.

---

In summary: For PItoPI interfaces collecting exception data, workload balancing is best achieved by deploying multiple interface instances—not by using multiple scan classes with the same frequency. Focus on Update Manager tuning, appropriate scan rates, and interface architecture to optimize both performance and reliability.