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
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.
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: f115013
We have a running experiment on off2 to rate limit image access with nginx.
See #255
It's still in dry run mode to study how it works.
The text was updated successfully, but these errors were encountered: