Would it be a problem to have a large number of enhanced services in one DMS (possibly containing 1 DMA only)?
We’re talking about up to 10 000 enhanced services in one DMS. Each enhanced service would need to subscribe to the parameter state of up to 12 parameters. This means that in total, we’re talking about 120 000 subscriptions in one DMS.
If yes, what would be the problem? The fact that we make so many subscriptions? Or the update of the parameters? (We don’t expect an extreme number of updates, as we’ll mainly subscribe to alarm states, not to values.)
On request of Flávio Jacinto who contacted me with additional questions on this topic and for this project.
Please be aware that SLNet subscription in their current form is a technology meant to be used for small scale scenario’s to receive very fast updates of data across the dataminer setup. Where you have either very few subscriptions or short-lived ones.
Use of this in large scale scenario’s has proven itself to be an easy way to overload a system in the past, especially if used from within QActions and SLScripting.
Wouter briefly touched upon it in his answer, but I want to make sure it is completely understood. “For every generated event, that event needs to be matched against all subscriptions to know whether a client needs to receive it.”
SLNet Subscriptions work fantastic on a small scale. But can very quickly have a larger impact.
The reason for this is that every ‘event’ that triggers, will loop through and execute EVERY single handler that was made on the SLNet connection.
For example:
Element 1, Quickaction 1: I make 20 subscriptions, for 20 parameter values.
The SLNet connection now has 20 possible triggers that will start an event.
Every event will loop and execute 20 pieces of code.
On Element 2, QuickAction 3: I decide to make 50 subscriptions, for 50 Alarm States on different elements.
The SLNet connection now has 70 possible triggers that will start an event.
Every event will loop and execute 70 pieces of code.
As you can see, every subscription made in a quickaction, doesn’t just increase the number of triggers. It also effects how many pieces of code need to execute for the other events. All quickactions use the same SLNet connection, so they share everything.
Do not use this technology (SLNet Subscriptions) on a large scale as it currently exists. It’s not intended for this and would require some software adjustments before it can be done.
Depending on the speed of polling, but it’s very likely going to be better yes.
If you make the polling speed configurable, it will also open up a lot more freedom to tweak the speed later on while monitoring resource usage.
The best way would be to work the other way around.
Have the source element do an external element set to the specific enhanced service when it noticed the data or status changed.
Although that is often not possible due to this requiring you to change the source protocols which are often times generic.
Though by all means, try out the different strategies and collect some hard metrics. Measuring is always the best way forward. Our software is constantly improving over time so you may notice it works for your setup. Though from experience I think you’ll have more luck with a polling or hand-crafted dedicated push strategy.
The DataMiner Metrics (as specified in the documentation) specify that the maximum number of enhanced services per DMA is 1000. This is mainly because each enhanced service is hosted by a background element running the enhanced service driver.
A lot depends on how heavy the enhanced service driver is.
As for subscriptions, no metrics are currently available:
- Less is better 🙂
- Subscribing on something which doesn’t update very often will still have a bit of processing impact: for every generated event, that event needs to be matched against all subscriptions to know whether a client needs to receive it.
- Subscriptions on parameter values are heavier
So from all those enhanced services it’s better to poll the 12 parameters instead of making subscriptions to it?