You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 wellOption 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.
The text was updated successfully, but these errors were encountered: