Bugs Everywhere Bug List

Bug: e9e/ae2

ID : ae2995de-0b30-43d2-a8dc-85dfc962108d
Short name : e9e/ae2
Status : open
Severity : wishlist
Assigned :
Reporter : adam j hartz <hz@mit.edu>
Creator : adam j hartz <hz@mit.edu>
Created : Tue, 28 May 2019 12:40:19 +0000
Target : v2019.9
Summary : Smart, Customizable Log Caching

Comment: --------- Comment ---------
ID: ce036466-3fcf-4845-9286-9954f7d4de92
Short name: e9e/ae2/ce0
From: adam j hartz <hz@mit.edu>
Date: Tue, 28 May 2019 12:48:50 +0000

Currently, several courses have gradebooks that are really slow because they
need to loop over _all_ of a student's activity to determine their scores.
This is incredibly slow, and if enough students load their gradebook
simultaneously, it can effectively accidentally act as a DoS attack.  It would
be nice to add a way to allow courses to specify information that should be
cached for every problem (or for every user, or....).

Maybe this is a group of two functions:

* cs_update_user_page_cache(old_cache, submission), which updates a
  per-user-per-page cache (every user has a cache per page).

* cs_update_user_cache(old_cache, submission), which updates a per-user cache.

I'll need to think a bit more about the form these functions take (and whether
the above are the two types of caches that make sense).  But it's a really nice
idea that can prevent some progress/gradebook pages from being a really sticky
river late in the semester.

Comment: --------- Comment ---------
ID: f6f7cf69-cc1f-49de-a6f5-0363594b6e63
Short name: e9e/ae2/f6f
From: adam j hartz <hz@mit.edu>
Date: Tue, 28 May 2019 12:52:37 +0000

I think this depends on #25, since per-user-per-course logs can be huge, and
the current log format is really slow on big objects.