habitat-sh / habitat

Modern applications with built-in automation
https://www.habitat.sh
Apache License 2.0
2.61k stars 315 forks source link

Investigate feasibility of rate-limiting in the Supervisor #7388

Closed christophermaier closed 3 years ago

christophermaier commented 4 years ago

Depending on the environment in which a Supervisor is running, it may be desirable to have it be able to rate-limit its network activity. This can be of particular concern with customers running Supervisors in low-bandwidth locations, where the Supervisor must share that bandwidth with other important uses. Network QOS configuration is a solution, but may not always be available.

Though the Supervisor uses the network for gossip, the more pressing concern appears to surround the downloading of new packages for service and supervisor updates. As such, the Supervisor would need some way to either limit each of these individually, or limit them all collectively.

christophermaier commented 4 years ago

Ideally, I think I'd want to target package downloads for throttling first, as opposed to all Supervisor network activity, which would include gossip. I'd certainly want to treat those two classes of activity separately; it would be bad for gossip activity to get throttled relative to download activity, since the former is vitally important to the operation of the system as a whole.

One idea I had is to implement a kind of wrapper around our HTTP client that can inspect the progress of any HTTP request futures that are in flight and keep them throttled as necessary to stay within some configurable bandwidth limit. The Tower project has some interesting composable middleware functionality that is at least architecturally along these lines. They have a few interesting implementations that do rate limiting kinds of things, but it appears to be more of the request-per-second kind, rather than Mbps-per-second, which seems to be what we'd want. I haven't yet seen an obvious way (outside of patching hyper or reqwest) to get insight into the amount of bytes a request has received yet, though.

I think there are some other easier changes we can make that will reduce our network usage that we should tackle before we dig into this. It could still be useful functionality to implement at some point, though, so we'll keep this card open for now to capture additional usecase information, implementation ideas, etc.

christophermaier commented 4 years ago

Also, if we took that approach, we'd probably want to keep one API client around and re-use it for each installation call, rather than having each installation call create a new client instance each time.

https://github.com/habitat-sh/habitat/blob/b6b5634c57da84b3bd7fa7d7d6e2cee0ee19e316/components/common/src/command/package/install.rs#L313-L315

https://github.com/habitat-sh/habitat/blob/b6b5634c57da84b3bd7fa7d7d6e2cee0ee19e316/components/common/src/command/package/install.rs#L337

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

stale[bot] commented 3 years ago

This issue has been automatically closed after being stale for 400 days. We still value your input and contribution. Please re-open the issue if desired and leave a comment with details.