[Dashboard] graph loading speed is too slow

[ori-near]

Problem

Currently, the graph loading speed is way too slow (e.g. at worst I've observed close to 45 seconds) for the dashboard graph.

Acceptance Criteria

• Investigate if there's an easy technical solution for solving this (time box this to 1/2 day)
  • If we identify a quick solution (e.g. 1 day), let's implement it
  • If we don't identify a solution, let's make a decision (e.g. do we accept slow loading, do we implement a loading progress bar, or do we hide or move the graph temporarily)

[FREZZZBE]

@petersalomonsen @rubycop @Megha-Dev-19 @Tguntenaar Do you have any ideas?

[rubycop]

Can we try to use our indexer for that? @Tguntenaar is it fast to implement?

[Tguntenaar]

As a temporarily solution I've scaled the fly machine in multiple ways. First we keep the cache warm by always having a machine on. Secondly I scaled from 1 to 2 CPU's and 1gb to 2gb of RAM. I've also add 512mb swap_size_mb for memory spikes. If this doesn't speed it up the chart enough we can persistently cache the https://archival-rpc.mainnet.near.org responses. Not just in memory.

One concern with this implementation is that the archival node will reduce it's rate-limits even further on February 1st. So the fly instance will get rate limited and so we NEED to make a more persistent cache, with Redis or Postgres.

[Tguntenaar]

@rubycop We could also speed up the chart loading by prefetching the different periods data and not refetching when a user switches between periods. AKA by lifting the API call logic up.

I will start implementing this now.

[Tguntenaar]

I made 2 PR's, they both significantly upgrade the speed.

NEAR-DevHub/ref-sdk-api#6
and
#250