Performance

Dashboards are active resources that may have significant performance impact. An "engine" of a dashboard is its bindings.

A dashboard running in a web browser may cause considerable CPU load and memory usage of the browser itself, Iotellect Server, or both.

Dashboards's CPU load impact is a multiplication of the following:

• Number of dashboard instances launched by system operators.

• Number of dashboard's bindings.

• Frequency of dashboard binding processing. It may either be explicitly specified in the binding options (for Periodic bindings) or implicitly defined by the frequency of events or state changes that trigger binding execution (for On Event bindings). See Bindings Performance for details.

• Complexity and impact of binding expressions. See expressions performance for more information.

• Impact of writing binding targets. Writing a binding target is in most cases writing a context variable or calling a context function. See variables performance and functions performance for more information.

• Usage and parameters of dashboard caching mechanism

Running dashboards that have hundreds of complex dynamic components (such as tables, event logs, or maps ) may cause considerable constant browser-side memory load.

Running dashboards may also cause additional short memory usage bursts in case if large datasets (e.g. lots of historical events ) are loaded by dashboards bindings or charts.

Modern web applications assume very short page loading times. To make a web dashboard rendering time as short as possible, it's recommended to minimize the number of startup bindings.

Only bindings that render information that must be seen by a user at very first seconds should be running in "startup" mode. All other dashboard initialization bindings should be started upon shown event of dashboard's root panel, which will essentially happen once the page is already displayed in browser window.

The above performance tweak is especially important for bindings that render information which is initially hidden from user's eyes, e.g. content of non-default tabs of a tabbed panel.

Dashboard loading times can be significantly affected by client-side applications that scan incoming WebSocket and HTTP/HTTPS packets. Certain antivirus applications include features for this type of active web traffic scanning, which can have side effects of using significant client CPU resources, and worsening web page responsiveness.

Whitelisting, or otherwise excluding from scanning, the URLs serving the Iotellect Web UI can significantly improve client-side performance in this case of degraded dashboard performance.

Was this page helpful?

Tell us more

Send

Thank you!