Is there a limit to how many events per second the PI Web API can send to the data archive?

We are working with a PI Adapter and are egressing the data to the PI Web API. I believe the adapter has the ability to send 20k events per second to the PI Web API but that the PI Web API can only comfortably accept 4-9k events per second. Does that mean the PI Web API can also only send 4-9k events per second to the data archive? If we have more than 9k tags that we want sent to the PI Web API, do we have to create additional PI Web API instances?

  • Hello ​ ,

    PI Web API and especially the OMF endpoint is optimized for performance. 4-9k events per second appear way too few. Please reach out to Technical Support and make sure you have the PI Web API version ready. At first, I would want to check the PI Web API Admin log and look at the Performance Metrics.

    Best Practices and Performance Improvements for PI Web API Requests is a very general article about do's and don'ts with PI Web API. Because the data is sent by a PI Adapter, I would assume 'no-cache' is not used but you never know. Individual requests and the belonging responses are written to the PI Web API Debug log when enabled. This log will fill up soon but allow to verify the headers included with the Requests send.

  • Hi,

     

    There is also a bug in the OPC UA adapter when dealing with enumeration types of signals e.g. RUNNING/STOPPED/STANDBY or TRUE/FALSE or OPEN/CLOSE.

     

    The adapter tries to create a new Digital State for each and every tag, without considering the fact that multiple tags have the same set of enums. e.g. if you have 1000 valves and there are then 1000 tags which can say OPEN/CLOSE, then the adapter will first start to create 1000 digital states in your PI Data Archive before it writes a single data point. The effect is that (1) your digital states list will be a total mess, and (2) it may seem like there is a performance limit at the webAPI.

     

    This is contrasted with the OPC UA Connector which is aware that multiple tags may share a single Digital State, and does not create a mess in that case.