The art of simplicity

I think that is the clearest blog title I used in years. Why do I mention this? Let me explain... Some time ago we stumbled over a performance issue in our applications. The root cause was a fragmented index, caused by the usage of a standard guid instead of a sequential guid. While looking for the right fix, I had to revisit one of my own posts: Sequential GUIDs with .NET 9 . In that post I mentioned that you can use Guid.CreateVersion7() to create a sequential guid. That is technically correct, but it is NOTa solution for SQL Server. Why does a random guid hurt? A clustered index in SQL Server is a sorted B-tree. When the key is random, every insert lands on a random page. If that page is full, SQL Server has to split it, which leaves you with half-empty pages, a fragmented index and more I/O. A sequential key always appends at the end, so pages fill up and stay put. Why is a version 7 guid not sequential for SQL Server? A UUID version 7 (RFC 9562) starts with a 48-bit U...

When talking to developers I get wildly different opinions about how "good" GitHub Copilot actually was for them. Some love it, some find it slow, some weren't sure it was doing anything useful at all(just kidding). The problem: nobody had any data. We were talking about token usage, latency and tool calls purely from gut feeling. GitHub Copilot can export all of that as OpenTelemetry traces, metrics and events. And the easiest way to look at it locally, without spinning up a cloud backend, is the Aspire Dashboard. Let's set that up. Why do we need this? Copilot isn't just autocomplete anymore. Every agent turn is a small orchestration: it calls a model, the model asks for tools, the tools run, the model answers. If you want to know where the time and the tokens go, you need to see that orchestration, not just the end result. That's exactly what the Open Telemetry integration gives you. Every agent interaction produces a span tree: invoke_agent copil...

Note: this is part 3 of a series on the Azure Monitor Profiler. Part 1 covered what the Profiler is, part 2 covered enabling it. This post is about the part that actually matters: making sense of a trace once you have one. Having profiler traces is only half the job. I've seen people enable the profiler, open a trace, stare at a wall of unfamiliar method names, and close the tab. The trace explorer isn't self-explanatory the first time - it took me a few real incidents before the views clicked. This post is the walkthrough I wish I'd had. Getting to a trace From your Application Insights resource: Go to the Performance tab Pick an operation from the list or leave Overall selected Click on Profiler traces   Pick one of the captured requests, ideally one with a longer duration than usual - that's where you'll actually find something. Once you're in a trace, you get two views of the same call stack data: Flame graph - the full...

Note: this is part 2 of a series on the Azure Monitor Profiler. Part 1 covered what the Profiler is and where to find the results - this post covers actually turning it on. There are two ways to enable the profiler: through app settings on App Service, or by wiring it into your code directly. Which one you need depends on where your app runs and how much control you want over the setup. Option 1: codeless enablement on App Service If your app runs on App Service (Windows) and your Application Insights resource is in the same subscription, this is the easiest path - no code changes, no redeploy. From the portal: In your App Service instance, select Monitoring > Application Insights Select Turn on Application Insights , then Enable Scroll down to the .NET or .NET Core tab Set Collection level to Recommended Under Profiler and Code Optimizations , select On Apply , then confirm with Yes Or skip the portal entirely and set the app settings directly...

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...

After upgrading our SQL Server Reporting Services (SSRS) environment, we noticed some isuses: reports were slow, users were complaining, and we had no idea where to start. The good news is that SSRS has been quietly collecting detailed execution data the whole time — and a set of built-in views makes it surprisingly easy to query. This post walks through the ExecutionLog views, what they contain, and how to turn that data into actionable performance insights. What are the ExecutionLog views? SSRS logs every report execution to the ReportServer database. Three views expose this data at different levels of detail: ExecutionLog — A simple view covering the basics: report name, user, start time, and duration. Good for quick lookups. ExecutionLog2 — Adds AdditionalInfo , an XML column with richer metadata such as estimated row counts and data source connection details. ExecutionLog3 — The most complete view. Breaks execution time into three distinct phases — TimeData...

The timeout appeared without warning. A migration pipeline that had run fine in staging suddenly ground to a halt in production, throwing lock wait timeouts across multiple worker threads. The application was querying and writing to the same table, and somewhere in that dance of reads and writes, things had seized up entirely. Here is a walk through the investigation, from the first diagnostic query all the way to the fix — along with an explanation of why it worked. Find the blocker The first tool in any SQL Server lock investigation is sys.dm_exec_requests joined against sys.dm_exec_sessions . This query shows you every session that is currently blocked, who is blocking it, and what SQL both parties are running: A second query dug into the exact lock modes held on the specific table in question: The output told the story The results were unambiguous. Three sessions. One blocker. Two victims. Blocking Blocked Wait type ...

I don’t do it on purpose but sometimes it can be so much fun to dive into an exception you’ve never seen before. You always come out with some new acquired wisdom. It all started with the following exception during the execution of our unit tests: System.InvalidOperationException : Operations that change non-concurrent collections must have exclusive access. A concurrent update was performed on this collection and corrupted its state. The collection's state is no longer correct. A look at the stacktrace brought us to the initialization system of our application where multiple modules are configured and initialized: at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior) at System.Collections.Generic.Dictionary`2.set_Item(TKey key, TValue value) at SOFACore.EntityFramework.EntityFrameworkModule.Initialize(IServiceCollection services) in /_/SOFACore/SOFACore.EntityFramework/EntityFrameworkModule.cs:line 30 Inside this mo...

When working with Entity Framework Core, understanding change tracking behavior is crucial for both performance and data consistency. While I was ware of the AsNoTracking() method, I discovered a lesser-known but powerful alternative: AsNoTrackingWithIdentityResolution() during a code review.  Let's explore what makes this method special and when you should use it. Quick recap: What is AsNoTracking()? Before diving into AsNoTrackingWithIdentityResolution , let's briefly review AsNoTracking() . By default, EF Core tracks all entities returned from queries in the change tracker. This tracking enables: Automatic detection of changes to entities Update operations without explicitly attaching entities Identity resolution (ensuring only one instance per entity exists in memory) However, tracking comes with overhead. When you're performing read-only operations where you don't need to update data, AsNoTracking() improves performance by skipping the change...

Yes! The new Visual Studio 2026 edition is available in preview (now called Insiders). I'll take some time this week to walk through some of the features I like and maybe some of the rough edges I discover along the way. One feature that is really new and only available inside VS 2026 (at the moment of writing this post) is the new Copilot Profiler agent. The profiler agent should be of assistant in any of the following tasks: Analyzing CPU usage, memory allocations, and runtime behavior Surfacing   bottlenecks in your code Generate new BenchmarkDotNet benchmarks Validate fixes with before/after metrics, all in a smooth guided loop And more… A good introduction of the profiler agent can be found here: But of course, we want to try it ourselves… Hello profiler! I have an existing set of BenchmarkDotNet test that I use to evaluate the performance of some features I’m working on and also to avoid that any change...

Serilog is one of the most popular structured logging libraries for .NET, offering excellent performance and flexibility. While Serilog comes with many built-in sinks for common destinations like files, databases, and cloud services, we created a custom sink to guarantee compatibility with an existing legacy logging solution. However as we noticed some performance issues, we decided to rewrite the implementation to use a batched sink. In this post, we'll explore how to build your own batched sink in Serilog, which can significantly improve performance when dealing with high-volume logging scenarios. At least that is what we are aiming for… Understanding Serilog's batched sink architecture Serilog has built-in batching support and handles most of the complexity of batching log events for you. Internally will handle things like: Collecting log events in an internal queue Periodically flushing batches based on time intervals or batch size limits Handling backpre...

As I gladly accept any kind of performance improvement I can get in my applications, I like to use the System.Text.Json source generator to generate the serialization logic for my Data Transfer Objects. However after upgrading a project to .NET 8, I started to get errors. The problem When using ASP.NET Core's [ApiController] attribute with automatic model validation, the framework automatically returns ValidationProblemDetails objects for validation errors. However, if you've configured your application to use System.Text.Json source generators for performance benefits, you might encounter serialization exceptions like: System.NotSupportedException: JsonTypeInfo metadata for type 'Microsoft.AspNetCore.Mvc.ValidationProblemDetails' was not provided by TypeInfoResolver of type '[]'. If using source generation, ensure that all root types passed to the serializer have been annotated with 'JsonSerializableAttribute', along with any types that might...