Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
Im currently analyzing a memory dump (.net 8 aspnet core app but I guess the same applies to net10). the app grows over time to up to 20 GB. I setup dotnet dump to capture a memory dump to analyze that twice a week so hopefully i will get a new dump next week with more insights. the current dump has a size of 8 GB. the live memory is 800 MB which is expected due to caching of entities and some singletons we create in our app. when I add the show dead objects filter the total grows to 3 GB.
so if you have any suggestions on figuring out where the other 4 GB went i would be glad. I tried dotmemory which also just shows 800MB. and ants memory profiler which is not able to load the dump file.
anyway what i found is in the dead object there are more that 1M Claims and 6M Strings most of them related to auth.
like the string Bearer, Bearer + the actual JWT token, then just the JWT. then the claims and their associated strings.
so here is my feature request / question:
I know that @davidfowl spend a lot of effort to make the transport layer do as few allocations as possible. are there any plans to reduce the allocations that occur due to auth?
or can you suggest an approch that i could implement to reduce these allocations. the requests the serivce get are mostly from other backend services so there are maybe 50 unique tokens + claims but as these services do many requests the transient garbage is in the millions of objects.
the app runs inside the official docker aspnet docker image. published with dotnet publish vanilla nothing changed.
are there any options you would suggest. I understand that the app should clean these stuff up as it is already marked as garbage in the profiler, but it seems it just does not.
Currently we just restart the app in a regular interval to avoid the out of memory issues that eventually occure. but our PMs are not happy with that approach.....
Describe the solution you'd like
f
Additional context
f
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
Im currently analyzing a memory dump (.net 8 aspnet core app but I guess the same applies to net10). the app grows over time to up to 20 GB. I setup dotnet dump to capture a memory dump to analyze that twice a week so hopefully i will get a new dump next week with more insights. the current dump has a size of 8 GB. the live memory is 800 MB which is expected due to caching of entities and some singletons we create in our app. when I add the show dead objects filter the total grows to 3 GB.
so if you have any suggestions on figuring out where the other 4 GB went i would be glad. I tried dotmemory which also just shows 800MB. and ants memory profiler which is not able to load the dump file.
anyway what i found is in the dead object there are more that 1M Claims and 6M Strings most of them related to auth.
like the string Bearer, Bearer + the actual JWT token, then just the JWT. then the claims and their associated strings.
so here is my feature request / question:
I know that @davidfowl spend a lot of effort to make the transport layer do as few allocations as possible. are there any plans to reduce the allocations that occur due to auth?
or can you suggest an approch that i could implement to reduce these allocations. the requests the serivce get are mostly from other backend services so there are maybe 50 unique tokens + claims but as these services do many requests the transient garbage is in the millions of objects.
the app runs inside the official docker aspnet docker image. published with dotnet publish vanilla nothing changed.
are there any options you would suggest. I understand that the app should clean these stuff up as it is already marked as garbage in the profiler, but it seems it just does not.
Currently we just restart the app in a regular interval to avoid the out of memory issues that eventually occure. but our PMs are not happy with that approach.....
Describe the solution you'd like
f
Additional context
f