Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Settle on a "consistent" caching mechanism #175

Open
3 tasks
ilan-gold opened this issue May 3, 2020 · 0 comments
Open
3 tasks

RFC: Settle on a "consistent" caching mechanism #175

ilan-gold opened this issue May 3, 2020 · 0 comments

Comments

@ilan-gold
Copy link
Collaborator

To optimize performance, especially when adding new channels, I think we should settle on a (few) caching solution(s), without assuming that the browser will handle this. I think there are two paths forward: a loader cache and a layers cache. I'll give an outline of where I see a solution in each.

One option would be to do something on the layers:

The TileLayer comes pre-loaded with a cache that works very well and can be set via a parameter, configurable both for number of images and size in bytes. I think we should fine tune this.

Furthermore, I think something similar, using a (potential) combination of more advanced state management (for adding new channels) and an actual explicit cache (for removing channels from state and then adding them back later), in the StaticImageLayer is possible. geotiffjs already has a built-in caching mechanism, which we would likely want to turn off as well, as anything that zarr has or will implement, so we are not duplicating our data stores.

Potential Steps:

  • Turn off the geotiffjs cache as well as any cache zarr may have.
  • Settle on an out-of-the-box cache size/strategy for the TileLayer.
  • Implement an explicit cache and/or more advanced state management for the StaticImageLayer.

Another option would be to have something on the loaders:

Basically, we would maintain a Map() on the loader of all made requests to their outputs and diff the current request's selection against what is in the map returning whatever is cached and HTTP-requesting whatever is not. The main hurdle here that I see is settling on an ID mechanism for the cache that is unified across both static and tiled imagery.

To my mind, the best solution is perhaps a mix of the two: optimize the tile cache inherited from the TileLayer (since it provides smoother visuals as well) and also implement a loader cache. I think this will take some experimenting to get right but I want to get the ball rolling. My idea here is to basically have one request for data per channel only once, using the cache the rest of the time. Perhaps this isn't feasible, but it seems worth striving for.

Thoughts?

@ilan-gold ilan-gold changed the title RFC: Settle on a consistent caching mechanism RFC: Settle on a "consistent" caching mechanism May 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant