Topology 3: Things to note

The following details were discovered or used in the building or testing of this topology:

1. Details related to PI Analysis Service management:

   1. It is important to tune the PI Analysis Service configuration for systems of this size due to the variability in analytic configurations.

   2. Cache parameters

      • MaxCacheEventsPerAttribute, MinCacheEventPerAttribute, and CacheTimeSpanIn Minutes should be adjusted based on the average event rate/analysis rate to minimize the cache missed count. Adjusting these parameters has an impact on memory usage.

   3. Thread count parameters

      • NumberEvaluationThreads, NumberDataWriterThreads, and NumberParallelDataPipes were increased during testing to improve latency times.

   4. Load shedding can be enabled depending on the specific use case. If it is enabled, the Evaluation Skipped Count performance parameter should be monitored. Manual backfilling is required to fill in any missing calculations. See Analysis service configuration.

2. Potential Impact on data quality if PI Analysis Service is not configured correctly:

   5. During recovery from downtime events, calculations may run using older data and that will cause expression outputs to have the wrong values. To avoid and correct this scenario, follow these best practices:

      1. Monitor the PI Data Archive Update manager for errors,

      2. Monitor the Evaluation Skipped Count,

      3. Monitor the Maximum latency for steady, continuous increase to an unacceptable level.

      4. To correct these situations, restart the PI Analysis Service and manually backfill all analysis for those time periods.

3. Systems with significant PI Web API or PI SQL DAS requirements:

   6. Resource sizing for Topology 3 is based on the performance envelope specified.

   7. Systems extensively using PI Web API queries or PI SQL DAS queries will likely be able to improve performance with additional hardware resources for the SQL Server node and/or the PI AF Server node.

4. AVEVA PI Vision scalability is specified using concurrent connections, which may not match the number of concurrent users if some users open more than one display at a time. Scaling of concurrent connections is heavily influenced by both the complexity and volume of unique analysis data reference attributes displayed in open PI Vision displays. For optimal performance in PI Vision, Asset Framework (AF) analyses should output to PI points.