This pull introduces a baseline implementation for caching responses. Currently, the feature is being demoed on /search only at this time. This pull also includes some large performance changes to the database queries that we use to form search results.
Based on local testing, an initial search query that contains 30 results per category (the maximum size) has an un-cached response time of about 30ms. When the same query returns a cached result the response time ranges from about 15-10ms, which is a 50-66% improvement on the initial response.
Search results have a cache lifetime of 30 minutes by default. Currently, all search results for tournaments, matches, and players are invalidated when any changes to their respective database tables are made. This could be made more efficient in the future by getting more granular in our invalidation. For example, currently all player search results are being invalidated when any changes to the base stats table are made (because we include information from base stats like rating in the search result). In the future we could only invalidate cached results that contain the BaseStats.PlayerId for the changed BaseStats instead of all results.
Using this baseline, we can slowly roll out caching for high traffic endpoints to improve responsiveness across the board.
myssto
commented
1 month ago
This pull introduces a baseline implementation for caching responses. Currently, the feature is being demoed on
/searchonly at this time. This pull also includes some large performance changes to the database queries that we use to form search results.Based on local testing, an initial search query that contains 30 results per category (the maximum size) has an un-cached response time of about 30ms. When the same query returns a cached result the response time ranges from about 15-10ms, which is a 50-66% improvement on the initial response.
Search results have a cache lifetime of 30 minutes by default. Currently, all search results for tournaments, matches, and players are invalidated when any changes to their respective database tables are made. This could be made more efficient in the future by getting more granular in our invalidation. For example, currently all player search results are being invalidated when any changes to the base stats table are made (because we include information from base stats like rating in the search result). In the future we could only invalidate cached results that contain the
BaseStats.PlayerIdfor the changed BaseStats instead of all results.Using this baseline, we can slowly roll out caching for high traffic endpoints to improve responsiveness across the board.