search

MIT-Tab / mit-tab

A Full Tabbing System for APDA Style Debate Tournaments.
MIT License
20 stars 24 forks source link

Cache debater and team rankings #156

Open BenMusch opened 5 years ago

BenMusch commented 5 years ago

that page load is a long boi

ifly6 commented 5 years ago

There is some kind of caching library or something of that sort, isn't there? Is it broken?

BenMusch commented 5 years ago

There is, but I haven't looked into the capability it has to store potentially really large lists

Additionaally, the current cache logic is just "cache the result for x seconds", but we may want more advanced logic along the lines of "cache the result until a round has been saved/updated/deleted"

ifly6 commented 5 years ago

Also, having worked with Django in something similar, it seems to me that this could simply be an optimisation problem in the tab_logic file. On cursory glance, many of the operations have a lot more IO overhead than are necessary for their specific calculations.

BenMusch commented 5 years ago

@ifly6 Yeah, I haven't really analyzed it too much but I'd imagine that there are loads of places which do a linear number of DB reads/writes which could be constant. For the most part, I'm not too concerned about that, just the tab_logic library is already super hard to read so I'm fine with sacrificing performance for the readability there

ifly6 commented 5 years ago

Looking at the rank teams response function, for example, it calls a method which calls total wins, speaks, and ranks. And then it discards those results after sorting, before calling those exact same outputs again to produce the final data set. I'd imagine the caching system would produce some efficiencies, but I've never noticed it speeding up on a second reload.

BenMusch commented 5 years ago

The caching is super short. It saves data basically long enough for 1 pairing process but doesn't hold onto data for more than a few seconds. So the way it's used right now would speed up duplicate calls during 1 page-load calculation, but would be unlikely to speed up the next page load

roddajohn commented 4 years ago

Two comments:

I think it's currently set to 20 second cache which is not long enough for a pairing process for a tournament of, say, 80 teams.

Second, I think we can add a higher level cache that specifically caches the team / speaking ranking result page that refreshes whenever a result is changed (can be achieved by overriding the save method on a Round and RoundStat to set a flag of like recalculate_stats. Upon thinking about it, this could help the pairings algorithm too.

And the tab_logic file is super unreadable so a higher level cache means we wouldn't have to touch it (woohoo) except maybe the cache_logic file.

BenMusch commented 4 years ago

@roddajohn yeah, agree with both of those. Cache for stats should be increased, but we should be caching the ranking lists in a completely different way. Feel free to take a stab at this, you may have to set things up using docker if you wanna test memcached

roddajohn commented 4 years ago

Will do, I'll put something real basic together.