Similar to this question Max Number of Parameter Subscriptions in DMS - DataMiner Dojo
There is a manager element which is configured to receive updates of metrics from multiple elements using subscriptions. These values change every minute or so. About 95% are cell values and 5% stand-alone parameters. At this point the element has about 4500 parameters which is subscribed to. There are some discrepancies between the values the manager element is reporting and the actual element which I'm guessing it has to do with the overall load of the system. As a temporary solution if we spread the load between different elements lets say 4 managers so each of them have about 1000 subscriptions would this improve things? Or since they share the same process would there be no difference? Would it be better to spread the managers on different DMAs within the cluster?
Hi Geovanny,
We had two major improvements on another project in which we did subscriptions from many to many. It is depending on your use case if these will also help your case. Some improvements to consider:
- Subscribing to table updates instead of to the cells themselves. For table subscriptions, you will only receive the rows that have been updated. This way you have fewer subscriptions which means that SLNet needs to go through fewer checks on every table update.
- In our case, we had many elements subscribing to similar parameters. This is why we manage the subscriptions in a static class. From the moment an element is created we initialize a static subscription manager in QActions. The manager handles all subscriptions of all elements running the same protocol & version. So they ask to subscribe to the manager and this one will then evaluate if there is already a subscription to the parameter. The manager will forward the update(s) to all elements that have asked to make a subscription to it.
The last option is quite complex and might take you quite some time to implement. If you go for the last option, we might evaluate if a standard library could be used. This way other projects could reuse the classes.
The manager element gets subscribed to parameters from elements like the Microsoft Platform, CISCO DMC along a few others so adding some logic to the source elements is probably not the way to go. I would keep in mind your other suggestions as I investigate further. Thank you!
In case the cells are really coming from different tables, there might not be that much improvement in subscribing to the complete table. Something else you might then consider is to add logic in the source elements, but if this means updating many protocols, then you might want to raise this topic with our data acquisition domain to evaluate the best option before making changes.