Super slow trend when selecting time span of 10 and 20 minutes

[ljamt]

No description provided.

[cesarcarc]

It is most likely related, but over time the application slows down. One scenario I have identified:

Action:

• Load House demo
• Let the application run as fast as possible (RT off)
• Open one of the trends, select timespan to be 10min.
• Let the application run for some time (3k seconds). After that, navigate to a model, try to override a value.

Results:

• Application as a whole is quite slow (not ok)
• Message size via websockets is around 2.2MB, even though the user is not in the trend view.

Action 2:

• Delete the plots and try to navigate

Result 2:

• Application is quick again (ok)

Notes:
I am removing the label "Client" as this is most likely connected to server-go. We should consider some sort of optimization such that we only receive trend data, when the trend is open.

[cesarcarc]

Note 2: By checking the plot "Room temp trend" (from House configuration), the websockets message size is approximately (for each timespan):

• 10s: 37kb
• 30s: 109kb
• 1m: 217kb
• 5m: 1.1MB
• 10m: 1.6MB
• 20m: 2.2MB

One initial quick fix would be to reset to 10s whenever navigating away from the trend.