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

Utilize caching much more aggressively #343

Open
BenMusch opened this issue Nov 6, 2023 · 0 comments
Open

Utilize caching much more aggressively #343

BenMusch opened this issue Nov 6, 2023 · 0 comments

Comments

@BenMusch
Copy link
Member

BenMusch commented Nov 6, 2023

Extremely trivial operations in mit-tab, such as loading a single team's view, can result in 50+ DB queries. DB queries are very slow in the grand scheme of things. 1 or two are fine! 50 is borderline unacceptable. The hundreds of queries it takes to pair a round is unsustainable for a small app.

Memory access is very fast! We should cache much more aggressively than we currently do. I have two high-level ideas here:

Option 1: Decorators

Right now we have @cache() decorators, but the cache hit rate is very low since we only cache for a few seconds. In reality, statistics rarely change. We can use some sort of logical-timestamp based system to figure out when a cache entry is expired. Details to this would definitely need to be sorted out -- if it's a global timestamp, we need to know things like "when team A has a round updated, does that affect the ranking of team B," etc. If a team-based timestamp is possible and useful, that may be an option as well

Option 2: Wrap the entire DB access with an in-memory system

Ultimately we don't need to have that much data for one tournament, it should be pretty acceptable to have a process which just stores every result in memory and flushes to the DB for persistence. If all of the access goes through this source it should be lightning fast.

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