Additional Diagnostics in Dependency Injection

[eerhardt]

The goal is to help customers better understand how their applications are running by adding events and counters that can give more insights and will help them debug potential performance issues. It'll also help us debug customer applications and write tools that would be able to glean insights from traces.

We would like to help customers better understand some statistics about registered services:

• How many singleton services?
• How many scoped services?
• How many transient services?
• How many container instances are in the processes?

Tagging subscribers to this area: @eerhardt, @maryamariyan
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The goal is to help customers better understand how their applications are running by adding events and counters that can give more insights and will help them debug potential performance issues. It'll also help us debug customer applications and write tools that would be able to glean insights from traces.

We would like to help customers better understand some statistics about registered services:

• How many singleton services?
• How many scoped services?
• How many transient services?
• How many container instances are in the processes?

Author:	eerhardt
Assignees:	-
Labels:	area-Extensions-DependencyInjection
Milestone:	-

[eerhardt]

@davidfowl - were you thinking that all 4 of the above would be "counters" (for example how many times services were resolved). Or do you think a single event during BuildServiceProvider that logs how many singleton, scoped, and transient service types?

[davidfowl]

Initially I was thinking counters but now I'm thinking event because they don't change throughout the lifetime of the app.

Also we need to add service provider instance id to the event and existing events since many can exists in the application (like in orchard)

[eerhardt]

but now I'm thinking event because they don't change throughout the lifetime of the app.

So you are thinking the count of types, and not the count of instances. Right?

add service provider instance id to the event and existing events

I assume adding info to an existing event isn't considered a "breaking change"

[davidfowl]

So you are thinking the count of types, and not the count of instances. Right?

Correct, instances can be found using an allocation profiler.

I assume adding info to an existing event isn't considered a "breaking change"

That's right.

[davidfowl]

I'm also thinking we should dump the list of registrations