In a recent code review, a colleague suggested using a typed HTTP client, as it could potentially offer better performance. The reasoning behind this is that the typed client leverages the ASP.NET HTTP factory, which can help avoid socket exhaustion. Interested in exploring this further, I decided to set up a performance test to compare the two approaches. # The tools For this test, I chose the following tech stack: - ASP.NET For making a simple web API to expose endpoints that call C# methods. - BenchmarkDotNet To handle benchmarking and performance analysis. Benchmarking is a new topic for me, and I’m eager to get started with it. # The HTTP implementations To compare performance, I created two implementations of a client class that makes HTTP requests. Both implementations are designed to test the basic task of making a request, checking if the status code indicates success, and returning a result based on that. ## Manual Client ```csharp namespace HttpClientLoadTests.Clients; public class ManualClient { private readonly HttpClient _httpClient; public ManualClient(HttpClient httpClient, string baseAddress) { _httpClient = httpClient; _httpClient.BaseAddress = new Uri(baseAddress); } public async Task MakeRequestAsync() { var response = await _httpClient.GetAsync(""); return response.IsSuccessStatusCode ? Results.Ok() : Results.StatusCode(StatusCodes.Status500InternalServerError); } } ``` The manual client sets up the base address for the HttpClient manually. The client is received via dependency injection and the base address is configured in the constructor. ## Typed Client ```csharp namespace HttpClientLoadTests.Clients; public class TypedClient(HttpClient httpClient) { public async Task MakeRequestAsync() { var response = await httpClient.GetAsync(""); return response.IsSuccessStatusCode ? Results.Ok() : Results.StatusCode(StatusCodes.Status500InternalServerError); } } ``` The typed client relies on the HttpClient that has been pre-configured via ASP.NET Core’s dependency injection system. This ensures that the client is set up correctly by the framework before use. # The ASP server To test these implementations, I exposed two simple API endpoints: one for the manual client and one for the typed client. Both endpoints call their respective client methods and return results based on the HTTP request outcome. ```csharp // Program.cs using HttpClientLoadTests.Clients; var builder = WebApplication.CreateBuilder(args); builder.Services.AddHttpClient(); builder.Services.AddScoped(); builder.Services.AddScoped(); var connectionString = builder.Configuration.GetConnectionString("endpoint"); builder.Services.AddHttpClient(client => { client.BaseAddress = new Uri(connectionString); }); var app = builder.Build(); app.MapGet("/manual", async (ManualClient manualClient) => await manualClient.MakeRequestAsync()); app.MapGet("/typed", async (TypedClient typedClient) => await typedClient.MakeRequestAsync()); app.Run(); ``` It’s a simple application that wil expose the HTTP interactions as endpoints. # The benchmark Using BenchmarkDotNet, I defined a benchmark that measures the time taken to make repeated requests with both client types. The benchmark includes multiple cycles to test how performance scales with the number of requests. I varied the number of cycles to assess performance under different loads, with 10, 50, and 100 cycles being the main test cases. ```csharp using BenchmarkDotNet.Attributes; namespace DotnetBench; public class HttpBenchy { private static readonly HttpClient HttpClient = new(); [Params(10, 50, 100)] // You can adjust the cycle counts as needed public int Cycles; [Benchmark] public async Task SingleHttpRequestManual() { string result = string.Empty; for (int i = 0; i < Cycles; i++) { var response = await HttpClient.GetAsync("http://localhost:9256/manual"); result = await response.Content.ReadAsStringAsync(); } return result; } [Benchmark] public async Task SingleHttpRequestTyped() { var result = string.Empty; for (var i = 0; i < Cycles; i++) { var response = await HttpClient.GetAsync("http://localhost:9256/typed"); result = await response.Content.ReadAsStringAsync(); } return result; } } ``` I’ve defined different cycles to also see how much the performance will scale over more requests. # Conclusion | Method | Cycles | Mean | Error | StdDev | Allocated | | --- | --- | --- | --- | --- | --- | | **SingleHttpRequestManual** | **10** | **3.402 s** | **0.4314 s** | **1.251 s** | **24.55 KB** | | SingleHttpRequestTyped | 10 | 3.858 s | 0.4633 s | 1.359 s | 23.28 KB | | **SingleHttpRequestManual** | **50** | **28.730 s** | **1.4549 s** | **4.221 s** | **112.94 KB** | | SingleHttpRequestTyped | 50 | 34.690 s | 1.7319 s | 4.828 s | 112.77 KB | | **SingleHttpRequestManual** | **100** | **17.744 s** | **0.7951 s** | **2.216 s** | **208.32 KB** | | SingleHttpRequestTyped | 100 | 18.283 s | 0.7066 s | 2.072 s | 211.8 KB | After running the tests and analyzing the results, I found that there was no significant difference in performance between the manual and typed client implementations. Despite the fact that the typed client utilizes the HTTP factory for connection management, this didn't result in any measurable improvement under the test conditions. I discussed these results with my colleague and justified my decisions. [Discussion mail confirmation (Image)](https://api.daaneggen.nl/uploads/http_bench_results_50645c25c4.png)

<DaanEggen/>

</>

In this article

Benchmarking HTTP Implementations

Because the web needs to be fast.

In this article