Bryan Owen

“PI Interfaces – Keeping it simple (Part 1)”

Blog Post created by Bryan Owen Employee on Feb 14, 2009

A recent upgrade activity was complicated by 80+ interface services running on the PI server host. Needless to say the upgrade took more than a few minutes!

 

PI interfaces can be very simple, and simple translates into very reliable. Reliability is the exact reason there were so many interface services. The system management team had taken the time to group points into multiple interface services because inputs were being polled from many different remote nodes.  In this case, the grouping strategy was based on commonality in connection path.

 

There are many other good uses for multiple interface services and point groups. Multiple interface services tend to operate in parallel and can also increase data throughput. If you don’t have redundant interfaces, dedicated services for high value and mission critical data can further increase reliability. Routine configuration changes and interface updates can also be organized by plant area to better align with operational schedules.

 

But how many is too many, is 80 interfaces too many?

 

The PI server is a beefy machine and this configuration has been stable over the years but the startup is taking a very long time.  It turns out LOCATION1 is still being used to group the points. This mechanism loads all points with matching POINTSOURCE from the server and then filters by LOCATION1 at the interface.  No wonder PIBASESS pegs, all the interfaces asking for all the points at the same time.

 

Changing to a unique multi-character POINTSOURCE for each interface service is a better approach (and 1 less location parameter to set).  The UNIINT startup cache mechanism delivers the best startup performance. 

 

Orderly start and stop is another defect.  Yeah, we forgot to update the site start and stop scripts too. 

 

So, 80 interfaces on one server are not all that simple after all.  We have more work to do.

 

 

Outcomes