Analyse performance improvement (Parramatta) dashboards

[lexvand]

Parramatta’s only complaint about their dashboard is the time it takes to load the (timeseries) tiles.

Determine what the actual bottleneck is, backend or frontend. And what would be possible measures to decrease loading times?

____________________________________________________________________________________________________________

Conclusion:
The majority of the delay (25 seconds up tomore then 60 seconds) seems to be in the Plotly engine.
I would like a second pair of eyes to confirm this findings

Analysis by Tom:
I inspected the network tab in both chrome and firefox but this was very confusing.
In chrome it seemed that the delay was because of the server.
In firefox it seemed that the first 20 seconds of delay was on server and last 20 second was on client
I therefore started commenting out code.

• If I comment out the plotly then the complete app is loaded in under 15 seconds in both chrome as firefox.
  Without unccommenting plotly this is at least 40 seconds and sometimes up to 1:30 minutes

Options:

• Pass plotly less data
  Plotly is now passed a lot of data: 16 graphs, 4 lines each, 100 values per line (p[robably more)
• make plotly refresh less often
  Each time new data arrives the entire dashboard is rerendered. Can we rerender lesss often or only rerender those updated tiles?
  I looked intoo this for the infinite api call problems but couldnot improve this. It was partly because of how react and redux are working.
• Choose another technology then plotly ( which may have similar problems)
• show less data on the dashboard, devide over several dashboards

___________________________________________________________________

CONCLUSION

after investigation together with Remco:

Cause:

The plotly library (or probably tiles in general) are retriggered to often.

We see that by commenting out plotly we reach a factor 4 improvement increase.

We should trigger Plotly less often to rerender.

This currently happens because each tile is connected to the whole store.

Possible solutions:

communication redux metadata only in container component (tile)
This component passes it as props to the chart.
Chart thus does not need to be connect te redux metadata
In short:
Container metadata,
chart real data.

In map state to props we need to filter only the data we need.
In shouldComponentUpdate we decide if the data is changed
___________________________________________________________________

[FRNT-240] created by joeri.verheijden

[lexvand]

Remco Gerlich

Hi Remco,
Feel like helping me by confirming my latest findings that Plotly causes the major hiccup?
kr Tom

by 5b3b278169812b2ef3f78d91

[lexvand]

Remco Gerlich

Hi Remco,

This ticket concerning the slow performance.

It is a problem for both Parramatta and the tile dashboard.

I think it is probably a important problem we need to tackle as soon as possible.

A similar problem might also happen with the 3di livesite.

kr Tom

by 5b3b278169812b2ef3f78d91

[lexvand]

Tom de Boer Remco Gerlich are you planning on using the plotly library in the new 3Di livesite? Then, i think, it’s good to inform Jonas of these known issues

by 5b03d19111b5d05139269675

[lexvand]

Yes, but the problem isn’t Plotly, it’s the fact that receiving a response for 1 timeseries request from the backend causes all the tiles to re-render. Everything in the dashboards is too interconnected.

This causes planning trouble with the 3Di live site, I’m emailing you about it now.

by remco.gerlich

[lexvand]

Ok. Thanks!

by 5b03d19111b5d05139269675