alexgarel
commented
5 months ago Today I take the opportunity to see if it was working as expected, and it's not.
In fact the rate limiter is triggered far too much.
Eg. for small images, I put 6000r/m (request per minutes) and it's triggered by a client who has only done 154 requests. As I though burst was about requests that would be above this thresthold, I put it to 100 for small images.
So I search for an answer and found one at https://stackoverflow.com/a/70989063/2886726 where a nginx blog post is cited:
In the example, the rate cannot exceed 10 requests per second. NGINX actually tracks requests at millisecond granularity, so this limit corresponds to 1 request every 100 milliseconds (ms). Because we are not allowing for bursts (see the next section), this means that a request is rejected if it arrives less than 100ms after the previous permitted one.
I didn't understood it was the way it worked ! So if we truly want to limit to 6000r/m, those request being eventually at the same time (as a browser might do), we have to set the burst to 6000 (all connection may arrive simultaneously). But if you send 6000 requests, you will then have to wait 1m/6000=1/100s to gain access to one new requests and one full minute to restore your 6000 request capacity.
I'm thus testing this configuration from now on… see: https://github.com/openfoodfacts/openfoodfacts-infrastructure/commit/f11501307448ebe6d0b3878678ae988705d3470f
We have a running experiment on off2 to rate limit image access with nginx.
See https://github.com/openfoodfacts/openfoodfacts-infrastructure/pull/255
It's still in dry run mode to study how it works.