Broadcast vs Report refresh
Hi,
We have a use case where we would like to display the contents of a report every 5 mins. At the moment, the setup consists of broadcasting the report to an email inbox every 5 mins, extract those values from the attached file and display it somewhere else.
We think a cleaner solution would be to embed the report in the external page using Javascript, however, from a performance perspective, is the load on the data source going to be the same in both scenarios since the report would be used on a third party 'dashboard' and would need the data to be no more than 5 mins old?
My understanding is that in the second scenario, the user would still need to set the report refresh to periodically, every 5 mins, hence, the data would be pulled every 5 mins. Would it be the same overhead compared to having a broadcast getting sent every 5 mins?
Thanks,
Nick
The same question
Hi Nick,
Great question! I had a chat with one of our Senior Devs and they agree that both JSAPI and broadcast run the report in almost the same way, but there should be a slight dip in CPU performance as there would not need to be an additional file generated (plus you would not need to use the additional overhead introduced by your extraction process), though there may be a slight increase in memory consumption as the data is stored there for longer.
I will also note with JSAPI, the user needs to be logged in whereas broadcast doesn't require a user session and there may be additional implications such as concurrency and access filter logic that come into play (though again, these should not affect performance, but good information to understand).
To summarize, the overall impact of the change on system resources should be minimal. Please let me know if you need any furhter details on this.
Cheers,
Neal
Hi Nick,
Great question! I had a chat with one of our Senior Devs and they agree that both JSAPI and broadcast run the report in almost the same way, but there should be a slight dip in CPU performance as there would not need to be an additional file generated (plus you would not need to use the additional overhead introduced by your extraction process), though there may be a slight increase in memory consumption as the data is stored there for longer.
I will also note with JSAPI, the user needs to be logged in whereas broadcast doesn't require a user session and there may be additional implications such as concurrency and access filter logic that come into play (though again, these should not affect performance, but good information to understand).
To summarize, the overall impact of the change on system resources should be minimal. Please let me know if you need any furhter details on this.
Cheers,
Neal
Hi Neal,
Thanks for that.
It just happens that we usually don't recommend [customers] having a broadcast sent every 5 mins as best practice in a PROD environment.
Based in the info provided, that would mean having a dashboard that refreshes the report every 5 mins or a report getting refreshed via JS won't make a lot of a difference.
I guess then the question should be more around how big the report is actually is (?)
Let me know what you think.
Thanks,
Nick
Hi Neal,
Thanks for that.
It just happens that we usually don't recommend [customers] having a broadcast sent every 5 mins as best practice in a PROD environment.
Based in the info provided, that would mean having a dashboard that refreshes the report every 5 mins or a report getting refreshed via JS won't make a lot of a difference.
I guess then the question should be more around how big the report is actually is (?)
Let me know what you think.
Thanks,
Nick
Hi Nick,
I suspect the size of the report in question will be the biggest bottleneck, and depending on the cluster setup may impact the front-end user experience if the broadcast was previously being handled by a separate, broadcast-only node. This would need testing your end to see what that looks like, but outside of that I don't see a large difference between the two.
Cheers,
Neal
Hi Nick,
I suspect the size of the report in question will be the biggest bottleneck, and depending on the cluster setup may impact the front-end user experience if the broadcast was previously being handled by a separate, broadcast-only node. This would need testing your end to see what that looks like, but outside of that I don't see a large difference between the two.
Cheers,
Neal
Thanks Neal.
No further questions from my side.
Regards,
Nick
Thanks Neal.
No further questions from my side.
Regards,
Nick
Hi Nick,
No worries, please let us know if you do need anything later on.
Cheers,
Neal
Hi Nick,
No worries, please let us know if you do need anything later on.
Cheers,
Neal
Replies have been locked on this page!