itsjoekent
commented
8 years ago Managed to get my old tool working that generates a bunch of users + gladiator imports
With 325 people that RB'd back for the entire contest it took ~10 seconds to load. My guess here is looping over all of these users is whats taking so long. I think using flash storage is a good step to improve the performance but it seems like it might make more sense on the competition level where all of the expensive aggregation is taking place.
If we really wanted to 💥 the complexity of this, computing all of this asynchronously & saving the results is the best bet. Have a button like "Calculate stats!" on the contest page which triggers a job to fire in the queue. The contest page would display whatever stats are currently saved & would require a refresh after the job finishes, but the app won't lockup while its computing. I hope that makes sense!
@weerd any thoughts / ideas you want to add?
What's this PR do?
Added contest-level statistics by aggregating competition statistics of specified contests. Tried to optimize performance by adding flash storage at contest level.
How should this be manually tested?
Keep track of each competition statistic for a contest. Add up these competitions statistics. Verify that these manual calculations match the statistics displayed in the contest site.
Any background context you want to provide?
None.
What are the relevant tickets?
Ref #343