EventListeners for CPU metrics


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


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

Performance Improving a Sudoku Resolver .net application

In this post, I will investigate how to improve the performance of a sample Sudoku resolver application. The base Sudoku resolver is a .net core console application written in C#. The original source has been written only in a couple of hours, while performance was not the main priority. In this post, I will gradually improve the performance of the application and document the process step-by-step. These articles will also touch on how some of the tools such as PerfView, dotnet-counters and BenchmarkDotNet can be used to measure performance. The goal of the optimization will be to reach a mean execution time below 500 us with a unimodal distribution and minimal allocation per run. By run I mean once the application is started, a run is parsing an input of a Sudoku and providing a solution for it. The application may execute multiple runs during its lifetime as a process. For repeatability of the performance tests, I have chosen a sample Sudoku input that is used throughout all the performance tests.

The goal of this post is to represent the ideas that may be used to optimize applications. I will try to avoid showing huge classes or large code, but I will show slices of the code that is modified in an iterative fashion. At this point, I would like to highlight that I am not optimizing the algorithm to resolve a Sudoku, I am optimizing the code that executes the algorithm to resolve the Sudoku. The algorithm itself will not change throughout the optimization process.

Why does performance matter in these days? In a cloud first, serverless world, where computation is bought on memory and CPU used by our application, we can only serve more request for the save money if our application is efficient - also we end up with a more "environment friendly application" by using less power with potentially less CO2 emissions.

Base Application

Find out more