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

.NET has good defaults for running in containers #5485

Closed
3 tasks
richlander opened this issue Oct 29, 2020 · 3 comments
Closed
3 tasks

.NET has good defaults for running in containers #5485

richlander opened this issue Oct 29, 2020 · 3 comments
Labels
area-docker bulk-closed Priority:1 Work that is critical for the release, but we could probably ship without Team:Runtime User Story A single user-facing feature. Can be grouped under an epic.
Milestone

Comments

@richlander
Copy link
Member

richlander commented Oct 29, 2020

People expect that the default behavior of .NET (or any container platform) is good in the general case. To a large degree, the conversation we had in Environment.ProcessorCount incorrect reporting in containers in 3.1 was about that, and we chose to bias default product behavior for the general case.

The assumption at this point is that .NET has good defaults, for the general case. The remaining work is to test this assumption. The following are cases that we will validate (and publish results). Please share if you believe that we should consider more cases, or if you have data to share. These cases are not a list of configurations, but guidance that we can document.

  • Define smallest container size that a .NET app can tolerate, with various load: 10, 100, 1000 RPS.
  • Define the smallest memory size that a .NET app can tolerate, with soft (--memory-reservation) and hard (--memory) memory limits set, with soft limit n% smaller: 10%, 25%, 50%
  • Define maximum RPS that can be achieved with a given CPU limit (memory is variable, documented): .5 CPU, 1 CPU, 2 CPU, 4 CPU.

Note: The tests will be run with API template.

Note: For these cases, only docker, not .NET, settings can be changed. The question is whether we are happy with the results we get, with .NET defaults.

@richlander richlander added User Story A single user-facing feature. Can be grouped under an epic. Priority:1 Work that is critical for the release, but we could probably ship without labels Oct 29, 2020
@richlander richlander added this to the Future milestone Oct 29, 2020
@nycdotnet
Copy link

I am greatly looking forward to this documentation. I would request that you go down as low as 100 or 250 millicores for an app, as densely packing containers - especially with techniques such as vertical pod autoscaling in k8s - is an attractive cost saving measure when possible. Also, especially for the resource constrained pods, I would love to see RPS figures for the first seconds and minutes of runtime rather than only in steady state. I suspect that adapting something like TechEmpower Fortunes would be a wonderful test case that is already optimized but does real-world work. We are so excited to see what you come up with for .NET 6.

@madhub
Copy link

madhub commented Feb 16, 2022

Also good add default GC for constrained environment . Today by default asp.net core apps select Server GC, it is issue for constrained environment like Docker/Kubernetes/Cloud Foundary.

@mairaw
Copy link
Contributor

mairaw commented May 26, 2023

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.

@mairaw mairaw closed this as completed May 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-docker bulk-closed Priority:1 Work that is critical for the release, but we could probably ship without Team:Runtime User Story A single user-facing feature. Can be grouped under an epic.
Projects
None yet
Development

No branches or pull requests

6 participants