Hello,

The best performance to receive value changes is to create a subscription. Sending read requests constantly will be inefficient compared to creating a subscription.

The RegisterNodes service is described in the following way in OPC UA specification:
“Service can be used by Clients to register the Nodes that they know they will access repeatedly (e.g. Write, Call). It allows Servers to set up anything needed so that the access operations will be more efficient. Clients can expect performance improvements when using registered NodeIds, but the optimization measures are vendor-specific.”

As a consequence, there’s no standardized expectation about the RegisterNodes service. Actually, it’s possible that the service offers no performance improvements whatsoever. You’ll need to check the server documentation or ask the server vendor if this service does anything at all.

One thing that can be said is that the RegisterNodes service should not be used to optimize Read service. If there’s a need for constant Read service calls, you should instead define a subscription to receive value updates. So in that sense, using the RegisterNodes in this setup does not make sense.

Hello,

It sounds like the actual issue is that the OPC UA server in question cannot handle 1700 monitored items. If this is the case, you should contact the server vendor and ask their opinion on how to optimize the server resource consumption.

As an example, defining longer sampling intervals for the monitored items and longer publishing intervals for subscriptions could lower the resource consumption of the server application. Please see some general communication parameters listed here: https://prosysopc.com/blog/opc-ua-sessions-subscriptions-and-timeouts/

However, as Jouni wrote above, it is not easy to say which one is the actual problem, client or server. Meaning that it’s still possible that actually the client application is the bottleneck in this case.

Generally speaking, RegisterNodes service is not related to OPC UA subscriptions. There’s no reason to expect increased subscription performance by calling the RegisterNodes service.

Hi Otto,

Yes, subscribing for data changes is exactly what you should do. The limitations that you are experiencing are not related to the OPC UA specification but they are practical limitations of the applications that you are using.

1700 monitored items is not an exceptionally large setup. Actually this is quite a normal amount of variables to monitor. Large OPC UA servers can sample even hundreds of thousands of monitored items simultaneously. However, you are using a relatively low powered device (embedded OPC UA server running on a PLC device) and it’s completely possible that you may have exhausted the server application resources.

The main problem here is a performance issue related to a certain OPC UA application. The subscriptions are the most powerful way of receiving data changes so you are not doing anything wrong in that sense.

You should start by finding out what is the bottleneck of the communication (client or server application). Then you could proceed to modify the communication parameters so that the bottleneck can handle all of the required data changes (as an example, create a smaller amount of monitored items until the data changes come through as expected). At this point, you can see if the performance is on a required level. If not, you can then report this performance issue either to the server vendor or to the client vendor, depending on what the bottleneck was. In this case we are the client vendor as you’re using our Java SDK to develop the client side application.