You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
0 commit comments