Prepare regional result geotiff zip files in blocking endpoint #987
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
log messages to assist in determining cause of slow file creation
Member
Author
|
@ansoncfit reports that on staging, fetching all GeoTiffs for regional analysis 63ab193ac84e4152d58fbb25 (~536k origins x 5 cutoffs x 5 percentiles) takes ~13 seconds to prepare, which is still too slow for a synchronous fetch. Interestingly running locally on exactly the same result grids, it takes only 3 seconds. I've added some logging to identify where the differences may lie when running on the staging environment. |
Member
Author
|
On staging, I observed producing the same GeoTiffs take 27 seconds, while zipping them and uploading to s3 took 300 and 400 msec respectively. It appears that only the read-intensive part of the operation is about 10x slower. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prepares regional result geotiff zip files in a blocking endpoint. These were previously prepared in a background task action because the process was very slow.
This PR reverses PR #938 which is hopefully no longer necessary after PR #986. I have tested this endpoint on smaller regional results (32k origins) but we should test it with much larger areas to ensure it's still reasonably fast.
The code does not take extra measures to prevent simultaneous requests for the same results, as this should not happen in usual operation from a web UI, and most actions taken are idempotent so the only expected side effect is wasted compute (and maybe exceptions from threads trying set files read-only while other threads are replacing them).