We recently introduced a rate limit for all requests to the satellite. What has been your experience so far?
0 voters
PS - If you can also indicate what your use case is that will help us understand the landscape a bit better.
I know that is rate limit
but i can’t understand question.
SNO does not ack satellite at direct. This makes the soragenode process developed by the Strojlabs.
I came here via an external link from a local forum, where they asked me to leave my opinion and vote. And I do not see from which thread this topic is located.
what forum was that?
I think good option if all clients can choose on satellite interface own limits (can be enabled by default)
We recently introduced a rate limit for all requests to the satellite.
I think the link for this introduction will be helpful for understand this question.
oh thanks. Now I can understand question and having thought well answer this pool
It was annoying to test the speed because of how the limit is implemented.
It says the limit is 30requests/second, but the actual limit is probably 3 requests/0.1second. This means I cannot start 29 requests at the same time.
There also seems to be a limit on active requests (but somewhat higher) - that means I cannot just put a sleep 0.1 between the requests.
A better way would be if the uplink had an option to block and wait for its turn, so I could start 50 processes at once and they would all complete (even if slower).
Uploading, downloading or deleting a lot of small files pretty much requires running uplink in parallel, otherwise it’s a bit slow.
Developer on the user growth team and strategy team here.
Wow, this is great! Thank you everyone for your votes and comments on the poll. Your input is very helpful for us to tune the request rate limit correctly.
We introduced request rate limiting between the uplink and the satellite to ensure a good quality of service for all uplink users. Without the limit it was possible for users to inadvertently consume most of the available database resources on the satellite and cause issues for other users. The intention was to pick a limit that would be mostly unnoticed by end users (as the typical use case shouldn’t hit the limit).
We needed to get the rate limit in place quickly to prepare for our production launch and unfortunately we fumbled this a bit. We didn’t take as much time as we might have liked to assess a reasonable rate limit and it seems we have tuned it too low. We are working to get better metrics into the code to tell us how often the rate limit is being reached and, with the outcome of this poll, we will pick a new limit soon.
Appreciate everyone’s patience as we dial this in!
Thanks for chiming in with some context @calebcase! It might be too soon, but I wonder how the different use cases affect results as well?