search

MetaCell / geppetto-scidash

Geppetto scidash extension
2 stars 1 forks source link

Performance analysis / caching #357

Open gidili opened 5 years ago

gidili commented 5 years ago

From @rgerkin: Every few seconds, and on load, a URL like this is retrieved. https://spike.asu.edu:8002/api/scores/?timestamp_to=2019-07-17T07%3A00%3A00.000Z&timestamp_from=2018-07-17T07%3A00%3A00.000Z&status=c. It takes about 2 seconds, which means even when the js bundle is cached, it will always take 2 seconds to load the page, even it is just going back to the main screen after visiting e.g. the login screen.

1) Do you think Dendrite will load a bit faster?
2) Could this have been cached better? Most of the time the content of that API call won't have changed. Could the server have sent a hash and if the hash is different it sends the whole thing, otherwise the client uses the cached version? I'm not asking for implementation of this, just wondering what is possible.

gidili commented 5 years ago

This polling mechanism is there because we need to check for updates to the score status (to update the UI if results are available etc). This cannot be cached because it's new info (status update, scores, etc) that we are retrieving from the server. But I agree we could look into the app performance as a whole to see if anything can be improved. Dendrite should load faster for sure because of the higher throughput.

rgerkin commented 4 years ago

It seems like checking for score status could be separated from loading all the scores (which I think is what it's doing now, and why it takes so long). Wouldn't it be fast for the server to hash score status (or even just the last-modified dates of every score, assuming these are auto-updated) either for the primary keys the user has loaded, or even for the whole database? Then SciDash can just ask the server where this hash has changed, and if not, then the server just sends a "no change" response.