Rate limiter should allow weights for different calls
Description
Merging PR 485 into master seems to have triggered 429 errors when loading users' profile pages, apparently because the query became more expensive (missing database index). Without the index (see ZNTA-2191), I'm sure it's much slower than it should be, but it's still a lot faster than uploading a document full of translations, so it would be good if the rate limiter reflected that.
Instead of the simple 2 active requests, 6 concurrent requests (ie queued) model, we should look at weighting different requests.
Most end-points would default to a standard weight, say 10, VersionService might be 1 (no DB access required), but end-points which upload entire documents might be given the weight 200 or more.
We could also look at calculating the true cost (eg processing time) of each call at the end for better resource allocation of later requests, just using the hard-coded weights as a starting point. (Calls which trigger asynchronous processing could make this tricky though.)
Merging PR 485 into master seems to have triggered 429 errors when loading users' profile pages, apparently because the query became more expensive (missing database index). Without the index (see ZNTA-2191), I'm sure it's much slower than it should be, but it's still a lot faster than uploading a document full of translations, so it would be good if the rate limiter reflected that.
Instead of the simple 2 active requests, 6 concurrent requests (ie queued) model, we should look at weighting different requests.
Most end-points would default to a standard weight, say 10, VersionService might be 1 (no DB access required), but end-points which upload entire documents might be given the weight 200 or more.
We could also look at calculating the true cost (eg processing time) of each call at the end for better resource allocation of later requests, just using the hard-coded weights as a starting point. (Calls which trigger asynchronous processing could make this tricky though.)