Thread Counters for Performance Metrics

In the previous posts I have looked into unit testing custom performance counters and interpreting the built-in CPU counter. In this post I will investigate on using some of the thread related counters. When using dotnet-counters we get a couple of useful counters:

Number of Active Timers                            0
ThreadPool Completed Work Items / sec             17
ThreadPool Queue Length                          703
ThreadPool Threads Count                           9

On the above sample we can see there are 703 work items queued on the ThreadPool, there are 9 threads in the pool, and 17 items has been completed since the last update, ~1 sec. This is a quite long queue compared to the work items completed in the last sec - should raise some concerns. Indeed my test application starts up a 1000 tasks, where each task uses the same lock to request mutual exlcusion for a code path which calls Thread.Sleep(). Another counter shows the contention on the locked object:

Monitor Lock Contention Count / sec               13

Find out more


EventListeners for CPU metrics

Introduction

EventListeners can be used to subscribe to built-in events of the .net core. In this post I will show how to subscribe to cpu-usage metric, and I will put the value of this event into context on different platforms.

There can be many reasons to subscribe to built-in events, especially to cpu-usage event counter. Although CPU usage can be monitored by a separate application (such as dotnet-counters), we might want to subscribe to this even within the process too. This way we may push the current resource usage periodically to an application metrics monitoring infrastructure (suck as the ELK or TICK stack). The cpu-usage counter measures the system and user time % used by the process.

The previous post has shown how the eventing infrastructure works within dotnet.

Find out more


Custom EventListener Testing

Introduction

The previous post has looked into creating custom EventCounters and testing them. In this post I will look into how to unit test custom in-process event listeners. The previous post has given an overview on the key classes and their behavior for event counters in .net core. Reading that post will help with the understanding of this post.

Custom EventListener

First, I will create a custom event listener, which listens for periodic updates from cpu-usage EventCounter from System.Runtime event source. I would like to test that the custom listener logic within this listener works as expected.

Find out more


EventListeners for Hardware Resources

EventSources and EventListeners

.net core infrastructure for event counters consists of a good couple of classes. This post will details the classes and their responbility when it comes to in-process event counting. I am writing this post by reverse engineering part of System.Diagnostics and System.Diagnostics.Tracing from their GitHub repo.

EventSource, EventListener, EventCounter (DiagnosticCounter), CounterGroup, EventDispatcher. Not all of these classes are relevant when simply creating or consuming counters, but we need a good understanding when it comes to testing. The purpose of this post is to detail their responsibilities and their internals.

Generally, to create our own set of counters, we would need to derive from EventSource class. In this class typically in the constructor we can create counters such as PollingCounter, IncrementingCounter, etc. Each counter has a name and a reference to containing EventSource derived class.

Find out more