OPC UA Server Performance Considerations

system:inmation provides a Server service component that can expose various types of data through the different interfaces implementing the different OPC specifications DA, HDA, A&E, and UA.

This document describes the usage of the OPC UA Server interface in terms of

Note: the current version of this document focuses on Data Access only, and does not take Alarms+Conditions into account.

The content of this document addresses roles that are responsible for configuring 3^rd party applications or services to connect to the inmation OPC UA Server and to read data from it.

Some detailed knowledge about OPC UA communication in general is expected, as well as awareness of the typical terms and abbreviations used in the OPC UA specification.

Additionally being familiar with system:inmation’s configuration of the server model and the interpretation of its performance counters is required.

If possible always host the inmation OPC UA Server service on a dedicated OS, not sharing resources with the Core. This will prevent a concurrency of the services for CPU and memory and distribute load for data processing and providing to multiple hosts.

OPC UA clients can create multiple sessions that each can consist of multiple subscriptions. In order to leverage from multiple CPU cores and parallel real time channels on the UA Server side, it is recommended to always use multiple subscriptions within a session.

For a high throughput of data changes per second use multiple subscriptions and multiple sessions (typically equals clients).

Note: Our testing environments use the .Net Core OPC UA client libraries. In our tests this client was not able to handle more then ~35.000 monitored items changing every second .
(https://github.com/OPCFoundation/UA-.NETStandard-Samples )

The Server service acting as OPC UA server starts requesting data from the Core service, when an OPC UA client creates a session and a subscription with monitored items. The communication between the two services is based on the internal inmation protocol SPROX, specifically the real time channel within it.

A real time channel is limited in throughput by the network latency between the two services, the available network bandwidth, and the CPU power required to communicate data over the TCP layer.

In low latency network environments (LAN, latency < 50ms) the maximum throughput is approximately 50.000 scalar numeric data points per second per real time channel.

Note: Non numeric data points, e.g. strings, can significantly vary in size and therefore can not be estimated very well. Since these types are typically of larger size they will lower the maximum throughput accordingly.

The Server service can open multiple real time channels to the Core in parallel. For each OPC UA session a separate channel will be opened.

Multiple subscriptions within one session will be processed in parallel, leveraging from the availability of multiple CPU cores. The total number of data points per second must not exceed the number of available CPU cores times 50.000.

For example a 4 CPU Server host must not exceed 200.000 data points changes per second in total.