Implement version_id cache for download endpoint using moka crate
#3999
Conversation
Turbo87
added
C-enhancement ✨
This comment has been minimized.
This comment has been minimized.
|
@pietroalbini I've move the env vars to the |
|
Generally yes, but I don't have time for a full review right now. |
|
☔ The latest upstream changes (presumably #4055) made this pull request unmergeable. Please resolve the merge conflicts. |
|
☔ The latest upstream changes (presumably #4061) made this pull request unmergeable. Please resolve the merge conflicts. |
Turbo87
force-pushed
the
moka
branch
6 times, most recently
from
1426518 to
1f91916
Compare
|
☔ The latest upstream changes (presumably #4090) made this pull request unmergeable. Please resolve the merge conflicts. |
Turbo87
force-pushed
the
moka
branch
4 times, most recently
from
823351d to
e649d92
Compare
Turbo87
force-pushed
the
moka
branch
2 times, most recently
from
f04d139 to
5cbddb6
Compare
|
☔ The latest upstream changes (presumably #4140) made this pull request unmergeable. Please resolve the merge conflicts. |
…ount()` to proper functions
This adds a caching layer in the app backend to reduce the number of database queries. While this query is extremely fast, a massive number of concurrent download requests can still result in a request backlog. In this implementation cached values are never dropped. This means that memory usage will grow over time, however the memory usage is expected to be well within our instance size and the application is automatically rebooted at least once every 24 hours. Additionally, on the rare occasion that a crate version is deleted, the cache will continue to serve redirects and attempt to record download counts for that version. If a version is deleted and continues to see download requests, it is expected that the entire shard of downloads containing that version_id will fail to persist. Even if we expired cached entries after a certain time period, there would still be a window where a deleted version could cause download counts for other versions to not be persisted. It is possible we could make the download counter logic robust against this scenario, but given that deleting versions is rare we can mitigate this by restarting the app after deleting crates or versions.
|
@bors merge |
|
@bors r+ |
|
📌 Commit b296c42 has been approved by |
|
☀️ Test successful - checks-actions |
This PR builds on top of #3848, but uses https://github.com/moka-rs/moka instead of https://github.com/xacrimon/dashmap for caching the
version_idin thedownloadAPI endpoint. I've implemented it using environment variables and default values that will allow us to fine tune the values in production, if necessary.