If your .NET API feels fast in development but lags in production, you’re not alone. Latency is a subtle killer — often hiding in plain sight, between network layers, middleware, or unexpected dependencies. You’ve profiled your database, optimized your LINQ queries… yet users are still seeing slow response times.
In this article, we’ll break down where your .NET API might be secretly wasting time — and how to actually measure that time using built-in tools and real-world tracing strategies.
🧩 The Usual Suspects (That Aren’t in Your Code)
You might be measuring only what’s in your controllers or services. But modern APIs rely on a whole stack — and slowness can creep in from:
🧱 Middleware (e.g., auth, exception handling, rate limiting)
🌐 DNS or network latency
🔌 External APIs
🔍 Serialization/deserialization
🔄 Unobserved async work (e.g.,
Task.Run, background threads)
Your logs might tell you the request took 40ms, but your user is seeing 500ms. Where’s the gap?
🧪 The Right Way to Measure: Tracing Every Layer
To measure actual response time, you need distributed tracing, not just ILogger calls. And you don’t need to buy Datadog to do it.
✅ Step 1: Add OpenTelemetry Tracing
Add the following packages:
dotnet add package OpenTelemetry
dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Exporter.Console
builder.Services.AddOpenTelemetry()
.WithTracing(t => t
.AddAspNetCoreInstrumentation()
.AddHttpClientInstrumentation()
.AddConsoleExporter());
✅ Step 2: Measure the Full Timeline with Activities
Want to see how long specific steps in your business logic take?
public class MyService
{
private static readonly ActivitySource _source = new(“MyApi.Service”);
public async Task DoWorkAsync()
{
using var activity = _source.StartActivity(“DoWork”);
await StepOneAsync(); // e.g., DB or API
await StepTwoAsync(); // e.g., processing
}
}
Each step becomes traceable, timestamped, and measurable — with no guesswork.
✅ Step 3: View Logs with Trace Context
Update your logging config to include trace IDs:
builder.Logging.Configure(options =>
{
options.ActivityTrackingOptions =
ActivityTrackingOptions.SpanId |
ActivityTrackingOptions.TraceId |
ActivityTrackingOptions.ParentId;
});
Now every log line includes a TraceId that links to a full request timeline.
🔍 Real-World Example: Why That API Call Feels Slow
Let’s say you have an API that calls an external weather service:
[HttpGet(“/weather”)]
public async Task<IActionResult> GetWeather()
{
var data = await _httpClient.GetStringAsync(“https://api.weather.com/…”);
// Some logic
return Ok(data);
}
With OpenTelemetry + AddHttpClientInstrumentation(), you’ll now see:
How long the outgoing HTTP request took
Whether DNS resolution was a bottleneck
If retries happened silently
That 200ms call you thought was fine? It might spike to 800ms on occasion due to transient latency — now you’ll know.
🔬 Beyond the Basics: More Ways to Measure
App Metrics + Prometheus — track actual percentiles (P95, P99) of response times
MiniProfiler — visualize query times, view rendering in MVC
BenchmarkDotNet — great for micro-benchmarking libraries or core logic
ETW / PerfView — for hardcore, low-level performance analysis
🚀 TL;DR
✔ Your .NET API can be “slow” even if your code is fast
✔ Use OpenTelemetry to trace real latency across the stack
✔ Add ActivitySource to your own business logic
✔ Log with trace context to connect the dots
✔ Monitor not just averages — but outliers
📦 Code Sample Repo?
If you’re publishing this article on a blog, consider linking to a GitHub repo with:
Minimal API project with OpenTelemetry
Simulated slow calls (e.g.,
Task.Delay)Instructions to test latency with
curlor Postman
Let me know and I can draft that sample repo + README.md for you too.