.NET Profiling for ASP.NET Core
Follow up from:
- https://github.com/getsentry/sentry-dotnet/issues/2315
- https://github.com/getsentry/sentry-dotnet/issues/1955
-
[ ] collect
Microsoft-Windows-DotNETRuntimerundown provider (loaded libs, etc) in a separate session and merge with actual samples later during processing, if possible (merging nettrace files, or having a custom provider for TraceLog). -
[ ] Or maybe we don't even need to collect these because we're in the same process? can we hack our way around and get the libraries from the current process instead? Probably not so easy because it also somehow stack walking if I'm not mistaken.
-
[ ] We'll use GlobalMode to set the behavior: all threads in process (global Mode) or only activity/request (server mode)
-
[ ] Consider capturing only the current "activity", i.e. not all threads but only what belongs to the transaction.
-
See also https://studylib.net/doc/6851938/eventsource-activity-support
-
possible blocker https://github.com/microsoft/perfview/issues/2122
Very exciting. How long do you think it'll be before external users are able to give it a go, assuming that we acknowledge that it's "alpha/beta caveat emptor" :)
First we need to get through #2315, which is blocked by https://github.com/microsoft/perfview/issues/1829
Then we can better estimate this one. It will likely be a while.
Blazor Wasm profiling available on .NET 10, I wonder if we can leverage that. Also:
- https://github.com/getsentry/sentry-dotnet/issues/3523#issuecomment-2877930809
Sentry releases Continuous Profiling support, with SDKs like Python and PHP.
Makes sense to update the ASPNET Core support to be on CP, since the current one is now called "UI Profiling" and doesn't really add a lot of value with so much Async code. Often just shows a few frames, or a bunch of async/await machinery and not much else