Hi,

I need to ask first some clarifications.

Which version of the SDK you are using for the client? Generally I would assume the latest release one if you do not specify (i.e. 4.3.0). If not, then please test with that one, in general any fixes would be on top the current release.

A single UaClient object is for a single connection, thus are you having 4 separate UaClients here?

While the version of the SDK for the servers doesn’t really matter that much here (assuming no bug influences the data sent etc.), it could still be useful to know. If by “ver 2.2” you mean 2.2.0 please note that it is very old.

There is … a lot of parameters that can influence this all in Subscription, MonitoredDataItem and UaClient. And in addition the common threadpools of the “stack layer” (or “the stack” if talking about SDK before 4.0.0) I guess in theory could be a bottleneck (though this would need a separate post; is complicated; but I think it should be probably something else before that anyways).

But let’s start by the most obvious one and continue in follow up posts once I’ll know the details listed above.

Can you tell what you are doing within the onDataChange calls? While removing blocking and synchronizations do affect (or well the synchronization only if you had 4 different UaClients call the same listener) performance, are you still e.g. doing individual operations per monitored item within the method (such as logging or calling anything that can take a bit of time). If we have 40k updates per second, this would mean you’ll have 1/40000 second timeframe per individual operation (as it is sequential per items per subscriptions), meaning if you are doing _anything_ within the method that takes more than 25µs (or 0.025 milliseconds) it will slow it down. If this was the case, then basically you should do a queue for which you will queue up some operations based on the datachanges and then do a mass-operation in a different worker thread etc. which could be faster (or if you notice the queue is filling faster than you can handle them that would be basically indication that something needs optimization e.g. SDK code, your code, hardware etc.).

Another, but not that pretty option is to attach a SubscriptionNotificationListener to the Subscription and check the onDataChange there. However in that case you would need to handle the raw NotificationData (which can be one of the subtypes DataChangeNotification/StatusChangeNotification/EventNotificationList), and would need to link the data with the client ids (which is basically what the SDK does for you when it calls the individual MonitoredDataItemListeners of the items). Anyway, SDK will still do most of the same calculations, so probably the queue option above is better.

Anyway you can use a profiler tool to check how long your onDataChange takes and try to see if it is too slow (do note then that the profiling itself does also slow it down so).

If you set logs to DEBUG level for Subscription, you should see lines “onPublishResponse: responseQueue.size()=” which will show how many responses are queued internally before our PublishTask Thread calls you listeners (needs more explanations I think). Anyway if that buffer overflows you will see a onBufferOverflow on a SubscriptionNotificationListener. By default per subscription the buffer size is 100 and can be set per individual subscription. Anyway, IF you do not see that filling, then it would mean we are not actually reading the notifications fast enough (which should not happen, unless thread schedulings prevent the Thread reading the raw socket from executing) or the server is not sending the data fast enough (given that it can only reply on the PublishRequests the client send, it could be an indication that we cannot send them fast enough). For those situations basically you should look using https://www.prosysopc.com/blog/opc-ua-wireshark/ (if possible, needs NONE or SIGN only modes to see traffic) is the data actually moving (and fast enough). In practice Wireshark is the best tool to see if network-wise everything makes sense.