Cost of subscription to RefreshStateSubscriber()

[Łukasz997 117]

I would like to share the results of an experiment: how much a subscription to events costs. It turned out that the cost is not as small as we might expect.

It reminds me of the results from another experiment - comparing access time to a QuickApp field (self.anyvariable) versus a local variable (or a global not bound to an object) - and how significant the difference is.

 

This is graph of normal, not very heavy loaded system:

Please login or register to see this attachment.

 

This is the same system with as low as 100 subscriptions added. Only catch the event and invoke near empty callback for every event. Empty house, nothing particular is happening...

Please login or register to see this attachment.

 

And a test code:

Please login or register to see this code.

 

[jgab 2,647]

Well, when you run them in one QA you only run one core at a time (it may jump between cores as your graph shows)
Running them on multiple QAs would spread the load more even and even out the graph. Point is, there is no reason to run multiple Refresh subscribers in one QA.
The number of callbacks (and thus work) also depends on how many events your system generates. 
Also when you press one core like that it starts to "trash" a bit - 30 subscriber gives a smaller smother curve.

 

So, I wouldn't worry about having ~30 QAs using refreshSubscriber on the the system - people have a tendency to write QAs that eat much more cpu on less useful things...

But yes, one should be careful with the resources on the HC3.
One approach is to have a single QA doing the refresh subscriptions and hand them out to the other QAs, like

 

and here is another one from the year before

 

Edited September 8, 2025 by jgab

[Łukasz997 117]

 

W dniu 9.09.2025 o 00:18, jgab napisał:

So, I wouldn't worry about having ~30 QAs using refreshSubscriber on the the system - people have a tendency to write QAs that eat much more cpu on less useful things...

This is the voice of reason.

My code was only an example. However, some kind of even simple System Monitor (not only a plot, not telling much) would be very useful in an environment with reasonably limited resources. No more guessing which QA is pushing the CPU so high. If anyone from Fibaro Company is reading this, consider it my suggestion.

 

Please login or register to see this attachment.

[jgab 2,647]

I did this some years ago.

but will of course not work with encrypted QAs...

[Łukasz997 117]

Interesting. This forum thread is a real goldmine of knowledge.
I joined to forum two+ years ago and never have enough time to read through it all - however it’s definitely worth it.