Expose event counters for performance metrics

[roji]

.NET Core 3.0 introduced event counters, which are a way to efficiently expose performance metrics from the application. For example, the .NET runtime emits various GC, CPU and JIT statistics. These can be read via dotnet counters.

Here is what we intend to implement for 5.0:

• Compiled query cache hit/miss statistics, allowing people to find bad queries which aren't getting cached for some reason. Could also provide some insight into query cache eviction (see Improve query cache eviction #12905).
• Basic query (total queries, query rate per second, query/command cache hit rates)
• SaveChanges
• DbContexts currently in use (initialized but not yet disposed)
• Execution strategy success/failure rate (per sec)
• Optimistic concurrency success/failure rate (per sec)

Other counter ideas have been moved out to #21931

[unaizorrilla]

Hi @roji

I like the initial proposal for :

• query executions ( current active connections, current transactions, number of query executions, number of query throws etc )
• query cache hits/miss

But it could be very intersting to have dynamic counters to see query execution time for specify queries (¿annotated with Tag, with a new metadata?). These dynamic counters allow us verify how "main" queries are working.

The image below is a sample of dynamic counters ( the first two [darkmode] and [matchscore] )

Besides, I'd also like to see counter for most of the EventId,RelationEventId,CoreEventId warnings like query client evaluations, execution strategy retrying, optimistic concurrency exceptions..

Thanks

Unai

[roji]

But it could be very intersting to have dynamic counters to see query execution time for specify queries (¿annotated with Tag, with a new metadata?). These dynamic counters allow us verify how "main" queries are working.

I'm not 100% sure, but from what I saw the design for event counters doesn't really allow for dynamic counters - you typically define a fixed set of counters that your component emits. What you're describing may be a better fit for a logging consolidation solution, which would ingest logs produced by EF Core (via DiagnosticSource), correlate events and produce the information you want. But it's worth thinking about.

Besides, I'd also like to see counter for most of the EventId,RelationEventId,CoreEventId warnings like query client evaluations, execution strategy retrying, optimistic concurrency exceptions..

Client evaluation is (mostly) no longer supported. Retries could be an interesting idea (added to the list), although it's a provider-specific feature which makes it a bit more complicated. I'm not sure what value there would be in counting optimistic concurrency exceptions, but it's certainly possible.

More generally, as I noted above, EF Core already generates lots of information via DiagnosticSource. Event counters are definitely not meant to replace that or mirror it - they're supposed to be a small set of well-defined standard statistics that can be emitted quickly and efficiently, and tracked in real time.

[unaizorrilla]

Hi @roji

I'm not 100% sure, but from what I saw the design for event counters doesn't really allow for dynamic counters - you typically define a fixed set of counters that your component emits. What you're describing may be a better fit for a logging consolidation solution, which would ingest logs produced by EF Core (via DiagnosticSource), correlate events and produce the information you want. But it's worth thinking about.

I do dynamic counters in my code and works well! I hope is supported :-)

https://github.com/Xabaril/Esquio/blob/master/src/Esquio/Diagnostics/EsquioEventSource.cs

[roji]

I do dynamic counters in my code and works well! I hope is supported :-)

Interesting idea, not sure it's 100% supported/safe but worth taking a look! Thanks.

[ajcvickers]

• Creation and disposal of a DbContext
• Calls to SaveChanges

Also, opening connections and using transactions would be useful, but should probably be at the ADO.NET level.

[roji]

Suggestion by @AndriySvyryd: counter for the number of service providers, to help locate problematic cases. We already have a warning for this case, and it might not be that valuable to have a perf counter for something that is essentially "boolean" (is your program working correctly or not), but something to think about.