Log In
Register
Forum
Topic RSS
15:23, EEST
November 29, 2021
Offline
Hi together,
I will first describe a little bit the address space of the OPCUA server:
There’s a node which contains about 200 components (children in my understanding ;)). These nodes contain again two components, say x and y
This means we have about 200 nodes x and 200 nodes y.
We listen to changes of these 400 nodes.
We have two subscriptions each containing 200 monitoredItems. One subscription holds the items which listen to changes of the x nodes and one subscription holds the items which listen to the y nodes.
We now have the problem that sometimes, many nodes (about 50-100) nodes change almost at the same time. Our OPCUA client is able to handle that, but following services are not able to handle this load.
I would like to improve the architecture to produce less load.
I’m searching for an elegant solution which is not hack n slash.
Of course I can do caching etc. on the client side, but thats always error prone and not ideal.
I thinking of a few options:
– Not listen to all nodes but instead invent a node with a boolean which we listen to. The server changes this value, and afterwards we read all x and y nodes and generate some event (would be fine for the following services, although I heard that this is not “best-practice” in case of OPCUA).
– SubscriptionNotificationListener: Implement this Interface and override “onNotificationData” and handle on Notifcation instead of handling the items on by one. However, it would still be possible that we receive multiple such notifications, right? For example, if 400 nodes are changed within 5 seconds, and the publishInterval is, for example 500ms. Then we could receive 10 notifications or even more.
– Somehow applying this idea: https://reference.opcfoundatio…..s/5.12.1.6 For example, I have one monitoredItem handling all 200 monitoredItems for x nodes. The monitoredItem checks every 5 seconds (for example), if at least one monitoredItem for the x nodes generated a notification, and reports this then via the subscription. This would mean we would have some event every 5 seconds which contains the info that at least one x node changed. Is this possible? If so, could you provide a code snippet how to implement? Because im not sure how to do it.
Many thanks in advance!
16:13, EEST
December 21, 2011
Offline
I wouldn’t make it more complicated than necessary. If your problem is that you receive too much data changes all the time, you should limit the sampling rate of the items, with a longer PublishingInterval for the subscriptions.
However, I understood that your problem is rather that you get too much data in bursts, in which case, you should design your client application so that it can take the data changes in and process them later to enable the temporary load. Basically, the SDK is already doing this for you, and the event handlers will get called as soon as possible, but they don’t limit new data coming in at the same time. So, we have decoupled the retrieval of NotificationMessages already from their handling.
Therefore, you don’t need to handle the onDataChange and onNotifiationData calls any faster than feels good for your application. They will get called eventually. Only, there is a limit to the internal buffer, and you will get an onBufferOverflow notification in the case that this buffer is not long enough to keep all the messages in the burst. By default this is 100 NotificationMessage long. One NotificationMessage contains one or more DataChangeNotification:s and each of these contains any number of samples for MonitoredItems. If you get onBufferFlow that is an indication that you get too many messages in and you may want to increase the buffer size (Subscription.setNotificationBufferSize) or need to limit the amount of data requested from the server with a longer PublishingInterval.
You can handle complete notifications with onNotificationData, instead of the individual onDataChange notifications for the MonitoredItem:s. However, it is not necessarily much faster, since the default handler just breaks the notification to separate calls for each MonitoredItem and doesn’t do much more.
Triggering (last item in your list) is not really related to this kind of topic. It rather means that the data changes are only sent when a triggering item changes. We don’t really support that in the Server SDK and i also don’t know about other server implementations. And for this case, it should not make a difference either, I think.
.
10:22, EEST
November 29, 2021
Offline
many thanks for your detailed reply. My client application handles onDataChange() in an async fashion; that is, it only produces events to some messaging queue.
The number of produced events in a certain time interval is what needs to be reduced.
As far as I understand, neither the samping rate or the publishing interval helps me here: For example, set the samping interval to five seconds, and the publishingInterval to 10seconds. The data of 100 nodes changes in the server within, for example, 5 seconds. Hence, I receive all changes within at most two sampling intervals, which are transferred to the client by one or two NotificationMessages. Say one notificationMessage. This NotificationMessage contains 100 samples of MonitoredItems, which are handled one by one. This would result on to much load for my application.
Handling onNotifiationData seems promising if I keep the publishingInterval relatively high (a few seconds): Then I could, if possible, sort the monitoredItems samples by a timestamp, and only process the newest monitoredItem (I could read all 400 node values and put them in the event)? Would this be a reasonable solution here?
13:55, EEST
December 21, 2011
Offline
I am not sure if I follow completely. But in general, if you get too much data, you will need to reduce the amount of data that you request or handle. The intervals are the only way to reduce the amount of data that you request. By buffering data and skipping some of it, is the second option.
So, I would just try to use PublishingInterval=10 s, if you think you need that long to handle the changes from all items. If you keep QueueSize for the monitored items at 1, you will get maximum one sample per item in every message. I don’t believe that there is a bigger difference, whether you use onNotificationData or onDataChange in this case. But, you can always try.
1 Guest(s)
