search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.25k stars 4.73k forks source link

Default trace events for .NET app performance analysis #64993

Open richlander opened 2 years ago

richlander commented 2 years ago

I'm doing some performance analysis of .NET apps. I'm working on Windows with PerfView, however this issue isn't intended to be Windows specific.

I'm new at doing performance analysis via our tools. Naively, I was expecting the following types of events to be available:

Note: I did find the first one.

It is entirely possible that I'm doing this wrong. It seems like basic performance analysis would be easier if these events existed and would compliment/compose nicely with custom events.

If these events make sense and we don't have them, do folks think we should start an effort to add them?

dotnet-issue-labeler[bot] commented 2 years ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

brianrob commented 2 years ago

There is an event for "about to start managed main", which is located here: https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/assembly.cpp#L1469. It's not ideal as is because to turn it on, you have to turn on lots of other events, but it does work. You must turn on the private provider, start-up keyword, and verbosity level of informational. It would be worthwhile to see how many of these other events actually fire, since some of them look to me like they could be specific to .NET Framework, but I don't know that for sure.

If we need to do work here, we should add a new event to the public provider just prior to execution of main.

tommcdon commented 2 years ago

@noahfalk

noahfalk commented 2 years ago

What I have done in the past is create a trivial EventSource and then instrument my example app to invoke them, but agreed that investigations would be easier if there were some events ready to go and it feels perfectly reasonable to ask for. Surprisingly @richlander you are the first person that I can recall to ask about it : ) @brianrob do you know if you or Vance got earlier requests for these types of events?

For Asp.Net there is an ILogger message here but no strongly typed ETW event that I am aware of. For Kestrel specifically I assume you could look at the AcceptStart event for System.Net.Sockets (https://source.dot.net/#System.Net.Sockets/System/Net/Sockets/SocketsTelemetry.cs,54). In my past investigations of ASP.Net there is a lot of work that occurs lazily when receiving the first request, so the first RequestStop event might be more meaningful. I filed this issue: https://github.com/dotnet/aspnetcore/issues/40238

brianrob commented 2 years ago

I've also done what you've done in the past @noahfalk. Vance and I haven't had other requests for this, but we have been the ones looking to request such things. If I recall correctly, this just never came to the top of the priority list at the time. I think overall, having some platform events to be able to measure reliably, especially for points in the app that occur in the platform, would be valuable.

That said, we don't always need to have a specific "startup" event - if we determine that something like AcceptStart is reasonable for web workloads, then that is OK for such scenarios.

Do you guys know which devs are maintaining WinForms/WPF these days?

We can probably just file an issue in https://github.com/dotnet/winforms and https://github.com/dotnet/wpf.

Application idle - this one seems ambiguous.

Agreed that this is app type specific. For example, I don't think of console apps as having an idle state.

Application terminating

I usually use OS process exit as well. This one is interesting if we want to pay attention to runtime shutdown. If we're going to do the exercise and add new events to be able to track app lifetime, this is probably worth having. Usually runtime shutdown is fast, but I have run into cases where it is not.

noahfalk commented 2 years ago

Thanks @brianrob!

We've now got: WPF - https://github.com/dotnet/wpf/issues/6138 Winforms - https://github.com/dotnet/winforms/issues/6646 ASP.NET - https://github.com/dotnet/aspnetcore/issues/40238

Usually runtime shutdown is fast, but I have run into cases where it is not.

What do you think should define the beginning of app shutdown, after we've returned from Main()?

brianrob commented 2 years ago

What do you think should define the beginning of app shutdown, after we've returned from Main()?

Yes, I think that's right. From there, everything else is pretty much runtime/process shutdown.

jkotas commented 2 years ago

What do you think should define the beginning of app shutdown, after we've returned from Main()?

That's over-simplification. The shutdown is app-model specific just like startup is app-model specific. Number of app models do a lot of (potentially asynchronous) work during shutdown before exiting Main. Some app models actually exit Main right away during startup and keeping the application running via non-background threads.

For Windows UI apps, the shutdown starts by user clicking the X for Windows UI apps. For container apps, the shutdown starts by the container orchestrator sending SIGTERM signal to the process.

noahfalk commented 2 years ago

I agree that there are app-model specific definitions of shutdown too. For me it was more if Brian and Rich are the proxy for users wanting this capability, what is the scenario that they believe is interesting to measure? If they (or others) want to measure a wide variety of app-model specific definitions of shutdown I'm happy to let folks enumerate all the situations they care about. Given that I'd never seen any asks on the topic before, my default response was to start with a very simple proposal.

brianrob commented 2 years ago

Yup, totally agree that not all apps will follow this pattern - depending on the apps we're looking at, we will need to select the right set of events for measurement.