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
Don't lock more than 1 row at a time in update-downloads
Prior to this commit, `bin/update-downloads` will hold a lock on every
row it updates for the entire batch of 1000. Each row gets locked when
it is `updated`, but the lock isn't released until the whole transaction
is comitted. This means that the first row in the batch is locked for
the whole transaction, but the last row in the batch isn't locked longer
than it should be.
Processing 1000 rows is routinely taking more than 30 seconds to
complete. Whenever it does, this causes requests to time out. Even when
it doesn't, this locking behavior is the reason that our 99th percentile
response time is getting to be so bad.
The endpoint affected by this is `/crates/{name}/{version}/download`. In
other words, this bug is causing `cargo install` to fail. Even when it
doesn't, this bug is causing it to take seconds when it should take
milliseconds.
By establishing a transaction per row instead of per batch, we retain
atomicity, without holding a lock for the whole batch. To keep
everything atomic, we need to update the global counter per row instead
of per batch.
This relies on the invariant that no rows in `version_downloads` get
touched once `date != CURRENT_DATE` other than by this script.
I believe this is also the root cause of rust-lang#1304, and that we can maybe
revert rust-lang#1312
0 commit comments