.NET can effectively scale with orchestrator configurations

[glennc]

In 3.0 we added support for CPU and memory limits so that we would honor constraints that an orchestrator imposed. That support works well, but there are few options to change the way .NET behaves when put in a constrained environment. I.e. choosing to optimize for density, throughput, or latency depending on your apps needs. We want to provide better configuration options for different customer scenarios as better data for customers to make decisions about what they want to optimize for and what constraints make sense for their orchestrator.

• .NET has good defaults for running in containers (.NET has good defaults for running in containers #5485)
• A customer can give hints about what to optimize for, relatively simple configuration i.e. single broad switch (A customer can give hints about what to optimize for, relatively simple configuration i.e. single broad switch #5488)
• A customer can determine what configuration they need from a running app ( A customer can determine what configuration they need from a running app #5490)
• A customer can have detailed, fine-grained, control over their choices
• A customer can determine what sized machines they would need for a set of apps

[mairaw]

Bulk closing .NET 6 epics and user stories. If you think this issue was closed in error, please reopen the issue and update it accordingly.