Important Note: To get reproducible results it is important to deactivate power-management, as modern CPU frequency scaling has a huge impact on the measured performance.
Windows: You can enable the Performance profile in the control panel -> Performance and Maintenance -> Power Options.
Linux: On Linux it depends on the used GUI (KDE, GNOME, etc.) how to disable power-management. On command line you can use cpufrequtils to control power-management. Anyway you can use the command 'watch grep "MHz" /proc/cpuinfo' to monitor the current CPU frequency.
Important Note II: Don't forget to disable the trace. The trace can have a huge impact on the server's performance.
Measuring OPC UA service calls:
The services Read, Write, Read with registered nodes, Write with registered nodes, Create/DeleteMonitoredItems are easy to measure, because they are triggered by the client. The UaExpert sends the service request and measures the time until it gets the response from the server. This is a kind of ping-pong scenario which allows to measure the response time.
Of course - by it's asynchronous design - OPC UA would allow to send multiple requests at once without waiting for the response. But this would be difficult to measure. If the server is slow, only the TCP input queue would be filled up, which means the client could send requests very fast until the servers TCP queue is full. The TCP/IP stack would then shrink to TCP window which leads to blocking sends on client side until the server has emptied it's queue again.
Measuring Performance of DataChange notifications:
In OPC UA DataChange notifications are sent via the Publish service. The performance of this service is hard to measure, as by design OPC UA sends only data that has changed and only based on the configured Sampling- and Publishing-Rates. So even if the performance of a server would allow to send the messages faster it will not send it faster than this configured rates.
However, there is a way to measure it:
- You need to configure a server which is changing all test values very fast, so that the datachange detection will always detect the value as changed.
- You need to configure very fast sampling and publishing intervals.
- The performance test client will measure if the configured publishing rate can be achieved.
- Then you constantly increase the number of monitored items, until the configured publishing rate cannot be achieved anymore. At this point you know what the maximum possible number of items in one DataChange for this publishing-interval is and you can compute the maximum transfer rate.