Create server-wide toke map. #186
Labels
No labels
Bug
Cleanup/Refactor
Core Feature
Documentation
Feature
Performance Improvement
Security Improvement
UX/Accessibility
Unreproducable Bug
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
#161 DB Dump Ingester
rainbownapkin/canopy
Reference: rainbownapkin/canopy#186
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Tokebot profile currently calculates out toke counts from the toke log. This is fine for smaller toke counts, but starts to show scaling issues, even when just handling existing tokes from our legacy site.
The statistics document should have a toke map, similar to standard user toke maps, which contain toke counts keyed by the command they're counting the usage of.
While it would technically be double-storing info, it would reduce the server-side computational complexity of rendering out tokebots user profile DRASTICALLY.
Looks like the tokebot part of userSchema.statics.findProfile needed tuning.
Calculating the tokemap wasn't the issue, and actually seems to be just as fast, if not faster, than pulling a map out of the stat document.
We probably need to drop the toke log from the stat document and make it it's own collection if we want to pull the stat doc any faster.
Refactored userSchema.statics.findProfile()'s tokebot profile generation procedure:
42ad17072fOnce toke logs are migrated to a dedicated portion of the DB, and tokebot profile pulls off of a minimized tokemap from the stats DB, we should consider caching certain server-side stats in RAM for quicker access.
Bad way of handling this. #187 makes more sense :P