With the current long pole in performance being download from S3 it seems like it'd be good to try out some level of caching.
An on-the-fly cache won't work well at all for the smaller, sync requests, as we'll limit people to smaller bboxes, so the chances of requests overlapping is almost nil.
For the short term the idea that seems most appealing is to pre-cache some areas. We'd download the s2 scenes needed to run the ftw model to local storage / ebs. The web-app could then highlight where users can expect faster results (so I guess we'd want some way to expose what scenes have been cached). To have this work well we'd want #12 in place, and would just cache the 2 recommended scenes. The web app / api would provide results other than those two scenes, but they wouldn't be cached.
Once we implemented bulk/async processing (#14) that could potentially build the cache (as it'd be much more likely to do full s2 scenes).
I will note this all may be more trouble than it's worth - it could be fine if we just really limit the sync response area and it's a bit slow, and focus more on the async response. We could let any user do a medium sized async area, and limit really big async / bulk requests so anyone wouldn't be able to just run it on full countries.
So just putting this up for discussion. It could be useful for the 'example' use case, like we could even just cache a few scenes that would then run fast, but not try to build some configurable / dynamic cache.
With the current long pole in performance being download from S3 it seems like it'd be good to try out some level of caching.
An on-the-fly cache won't work well at all for the smaller, sync requests, as we'll limit people to smaller bboxes, so the chances of requests overlapping is almost nil.
For the short term the idea that seems most appealing is to pre-cache some areas. We'd download the s2 scenes needed to run the ftw model to local storage / ebs. The web-app could then highlight where users can expect faster results (so I guess we'd want some way to expose what scenes have been cached). To have this work well we'd want #12 in place, and would just cache the 2 recommended scenes. The web app / api would provide results other than those two scenes, but they wouldn't be cached.
Once we implemented bulk/async processing (#14) that could potentially build the cache (as it'd be much more likely to do full s2 scenes).
I will note this all may be more trouble than it's worth - it could be fine if we just really limit the sync response area and it's a bit slow, and focus more on the async response. We could let any user do a medium sized async area, and limit really big async / bulk requests so anyone wouldn't be able to just run it on full countries.
So just putting this up for discussion. It could be useful for the 'example' use case, like we could even just cache a few scenes that would then run fast, but not try to build some configurable / dynamic cache.