Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Add a checkbox to deploy the changes to one server at a time. #222

Open
MaltronCraft opened this issue Mar 5, 2021 · 2 comments
Assignees
Projects

Comments

@MaltronCraft
Copy link

Would it be possible to a feature where if you checked the box, it would update one server at a time to avoid the Nitrado rate limit?

@thommcgrath
Copy link
Owner

Yes and no. I feel like some background is needed to understand what's going on. At the time of this writing, the default Nitrado rate limit is 15,000 requests per hour. This is exceptionally hard to hit under normal circumstances. However, thanks to a bug in Beacon 1.4's Servers editor, Beacon could be exhausting your limit much quicker than it should be. Selecting a server in the list causes Beacon to check the status of the server every 5 seconds. Leaving that server selected for an hour would mean 720 requests. The bug is that Beacon doesn't stop checking once you select another server, switch to another editor, or even to a different tab. So they pile up. If you've selected 5 servers, now Beacon is making 3,600 requests per hour. One user with 60 servers would find themselves burning 43,200 requests per hour and hitting the limit very quickly.

This bug has been fixed in Beacon 1.5. With the bug fixed, the need for such a checkbox really goes away. A typical deploy process will use around 12 requests for a server. You'd need around 1,200 servers to hit the limit. Beacon will struggle much more in other areas trying to make that happen.

Which is why something is being added, just not for the reason you were suggesting. Coming in Beacon 1.5.1, deploy and import requests will be throttled to a default of 3 requests at a time. The user could reduce that number to 1 to slow things down further. This doesn't deploy only one server at a time, only slows the connections. So if server A is uploading Game.ini, server B would wait for server A to finish, begin uploading its own Game.ini, and server A would begin waiting on server B so it can upload its GameUserSettings.ini. So the deploys continue as normal, but will fight less for bandwidth.

@thommcgrath
Copy link
Owner

Some of the work was committed in 1095e98

@thommcgrath thommcgrath self-assigned this Mar 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Beacon 1.5
  
Awaiting triage
Development

No branches or pull requests

2 participants