Tile Speed Reporter #34
Draft
Conversation
This file contains 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
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.
This PR is mostly just for testing, as it adds a pretty ugly button labelled "Report" to the top of the datasets drawer. This button will export the response time for each tile requested by the user during their session in the xreds viewer. It only resets on reloading the page.
Using this feature, I was able to determine what I believe to be the biggest benefit of the redis cache - the way tiles interact with
GetMinMax. AsGetMinMaxis called after the layer is first enabled / when the time/elevation is changed, the tile requests after those actions are the most improved by far. This could be huge to improve performance when proxied behind PyXMS, as PyXMS callsGetMinMaxbefore every tile request.However, this is not a very scientific way to test the speed of the tiles, as there are a lot of variables not accounted for by the report. Differences in user behavior and differences in network conditions can have a huge impact on the results, so I don't know if this tool is useful enough to be considered for merging into main.
Here are some of the results output by the tool, note the incredible difference in timing on the very first tiles after the timestep is changed.
ngofs2 redis.csv
ngofs2 no redis.csv
ciofs redis.csv
ciofs no redis.csv