Dashboard sidebars retrieve work and bookmark counts from Elasticsearch, which creates long running queries especially on users or pseuds with a lot of works and bookmarks. We need to cache these counts. The cache time should be configurable.
Series counts come from the database and they're not as much of a problem, but let's cache them anyway. See AO3-5829.
Note: We've added a workaround in nginx that renders /users/orphan_account/pseuds/* pages as 404. We can remove that once caching is in place.
How to test:
Check that the dashboard work count is eventually updated after a work is created / deleted / posted from draft / (un)revealed.
Check that the dashboard bookmark count is eventually updated after a bookmark is created / deleted / made private / made public.
215 works and 229 bookmarks at 1:42 local!
This seems a bit iffy:
Logged out, saw 219 bookmarks on dash at 2:35
Logged in as bookmarker, saw 229 bookmarks on dash at 2:36
Logged in as other user, saw 222 bookmarks on dash at 2:36
Logged in as admin, saw 229 bookmarks on dash at 2:37
Made one of the bookmarks private at 2:37
Went to confirm counts remained the same at 2:39, but noticed a discrepancy when logged in as other user (dashboard sidebar showed new count of 221, but bookmarks page sidebar showed 222), and the sidebar count had also decreased to 218 as the logged out user
At 3:08, logged in user saw 221 on both pages
At 3:08, logged in bookmarker saw 229 on both pages
At 3:09, logged out saw 218 on both pages
At 3:10, admin saw 229 on both pages
So the number on the two pages can get out of sync, but eventually comes out okay.
Tested work caching on mobile (Firefox). I deleted a work, and the count in the sidebar updated by the time 21 minutes had passed.
Tested bookmark caching, also on mobile (Firefox). The count in the sidebar updated after 18 minutes. The correct count was displayed both logged in and logged out.
In one test I did, the count in the main dashboard didn't initially update after I deleted a bookmark (normally it updates right away), but then it did after a refresh.
Staging is being awful, so we’re forging ahead and deploying this, hoping a) some of the weirdness was just staging being slow and b) it will keep the site running decently this weekend, because a site that is up with potentially wonky counts still beats a site that is down.