Benchmark Dashboard code and discuss/document possible performance improvements

[philippeluickx]

Current Dashboard performance is slow - loading is capped at 50K records and this query take 10s. There can be several places where Dashboard performance could be improved, so care should be taken before proceeding with any single solution.

Objective

Before going with further experiments, it is good to have a baseline measure of performance for comparison.

We should try to measure the overall time, on average, that the dashboard takes to render as well as time spent on each stage. This will give us better insight on strategies for optimization.

Rendering stages

There are a few stages involved in rendering the dashboard charts, including:

• fetching the data
  • server fetch from Elastic
  • client fetch from Meteor server
• parsing the data
  • e.g. aggregation or preparation of chart dimensions
• rendering the charts
  • e.g. creating DOM elements for data points, animations, etc

Each stage in the rendering sequence adds some amount of delay to the overall user experience.

Proposed changes:

• Aggregate data per day / response code / response time group (adds a count column)
• Remove data table (can be handled in different ways later: seperate request, download CSV, in a different view,...)
• Remove hourly - daily - weekly - monthly aggregation options

Next steps:

1. Proof of concept: only load first chart with aggregation on Elastic Search (365 records for 1 y)
2. Add response code aggregation (365 * 5 records for 1 y)
3. Add response time aggregation (365 * 5 * 10 records for 1 y) - we can group response time in 10 sections (0 - 100 - ... - +1000 ms)

Definition of done

• Benchmark(s) exist(s) for Dasboard code
  • Team understands, after discussion, sources of significant delay in Dashboard loading sequence
• Document exists describing possible enhancements for Dashboard code
  • Proposals have been objectively compared,
    • e.g. honest assessment of possible delays with each solution
  • Proposals have been compared by estimated amount of implementation effort
  • Document acknowledges any functional losses for each proposal (e.g. dis-integration of dashboard charts), as tradeoffs

[philippeluickx]

Docs: https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations.html
per term: https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-bucket-terms-aggregation.html
per date range: https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-bucket-daterange-aggregation.html
per range: https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-bucket-range-aggregation.html

Tutorial using ES aggregation with d3: https://www.elastic.co/blog/data-visualization-elasticsearch-aggregations

Another tutorial, e.g. stats (if not used already): https://blog.madewithlove.be/post/elasticsearch-aggregations/

[frenchbread]

As suggested in here - NatLabRockies/api-umbrella#140 (comment), there is a way to fetch analytics using API-Umbrella's REST API and it's more secure.

Analytics drilldown data should be accessible via this URL: https:://<domain>/api-umbrella/v1/analytics/drilldown. The problem is that currently I'm getting 500 error status code. Reported that issue in NatLabRockies/api-umbrella#275