How many Telemetry Objects is it reasonable to have?

[mgazic]

The tutorial looks to have 7 telemetry objects, defined in https://github.com/nasa/openmct-tutorial/blob/completed/dictionary.json, which is 185 lines, and 5211 bytes. The system I'm considering using OpenMCT for has thousands of telemetry points. Would that work with OpenMCT? If I try to use a dictionary.json to define them all and scale up from the example for 7 telemetry objects to 2000, then it would be about 50,000 lines long and 1.5MB, and I'm not sure if that's reasonable. I can of course remove whitespace and get the example 7 telemetry object dictionary.json file down to 1.68kB, but scaling that up to 2000 telemetry objects would still be about 460kB. I'll be using a script to generate the dictionary.json from another dictionary that already exists, so I'm not worried about creating it. I'm just worried about if giving too big of a dictionary.json file to OpenMCT will cause problems.

I'd also like to support subscribing to real-time telemetry for each of the telemetry objects, in addition to implementing a provide/request telemetry store. Does OpenMCT subscribe to each telemetry item as soon as it's placed on a plot? Or only if the plot is currently visible? Would it be okay to create lots of tabs and pages with perhaps hundreds of telemetry values in total plotted on dozens of plots, but with only a half dozen plots visible on screen at one time? Or would simply creating those plots, even if they're not visible, cause a large performance impact?

Does anyone have an example of how many Telemetry Objects their real system has, and how well OpenMCT supports it? I'd like to make sure my use case is reasonable before I go too far in to trying to make OpenMCT work with my system.

Thanks,
Miles

[milesbjackson]

Funny, my name is also Miles.

This week i got a system with 31 inputs at 60Hz so 1860 messages per second. Into more than 31 widgets on one page. all updating real time. Can't humanly detect any latency.

[jvigliotta]

@mgazic great question. We optimize our front-end extensively for performance. Many times, the issues you will run into will be limits of the browser or the hardware.

Regarding the amount of Telemetry Objects. We have implementations of Open MCT that have tens of thousands of telemetry objects and run without issue (if you’re downloading the dictionary in one go, it may take a while, but that’s related to network conditions). We also recommend caching your dictionary so subsequent retrievals can return the cached version. In Open MCT’s object tree, which is where the dictionary items would be displayed, we use “virtual scrolling” so that only the amount of objects that can be shown in the tree (plus 100 or so) are actually loaded into the DOM, so even if you have thousands of items, only 100 - 200 at most will be in the DOM at any given time.

Regarding telemetry, if you are viewing the plot then that telemetry will be requested and subscribed to if there are related telemetry providers available. Our plots will only request the amount of telemetry they are able to display based on pixel width of the plot. Again, we try very hard to make Open MCT as performant as possible, so you shouldn’t have any issues there. For Tabs, we have a setting in the properties called “Eager Load Tabs”, if this is set to true, it will load and subscribe to all telemetry in all tabs. If it is set to false, then only the tab you are currently viewing will have telemetry loaded, when you navigate to a new tab, then the telemetry on that tab will be requested/subscribed.

Hope this helps!