Understanding Slow API Requests and HTTP Connection Pooling in .NET

An API can become slow even when its endpoint code looks efficient. Sometimes the delay is not caused by database queries, business logic, or serialization. It can happen while the application is waiting to establish an HTTP connection to another service.

This is particularly common in applications that communicate with multiple external APIs, microservices, payment gateways, or authentication providers.

.NET uses connection pooling through HttpClient and its underlying HTTP handler to reuse connections instead of creating a new connection for every request. When the client is configured incorrectly, applications can experience unnecessary connection setup, socket exhaustion, increased latency, and inconsistent response times.

Understanding how HTTP connection pooling works helps developers build more reliable API integrations and diagnose performance problems that are difficult to identify from endpoint code alone.

1. Why API Requests Become Slow

Consider an ASP.NET Core application that calls an external service to retrieve customer information.

public class CustomerService
{
    public async Task<string?> GetCustomerAsync(int customerId)
    {
        using var client = new HttpClient();

        return await client.GetStringAsync(
            $"https://api.example.com/customers/{customerId}");
    }
}

This code looks simple. It creates an HTTP client, sends a request, and returns the response.

However, creating and disposing an HttpClient for every request can cause performance problems under heavy traffic.

Each HttpClient instance uses an underlying HTTP handler, and each handler manages its own connection pool. Creating a new client with a new handler repeatedly prevents the application from reusing existing connections effectively.

A new connection may require several steps:

1. DNS resolution to identify the server address.

2. TCP connection establishment.

3. TLS negotiation when using HTTPS.

4. HTTP request transmission.

5. Waiting for the server response.

These steps introduce additional latency before the application receives a response.

When the application sends thousands of requests, repeatedly establishing connections can become an unnecessary source of overhead.

Other causes of slow outbound API requests include:

• Connection pool saturation.

• Slow DNS resolution.

• TLS handshake delays.

• External service response time.

• Network latency.

• Large response payloads.

• Excessive concurrent requests.

• Missing timeout and cancellation handling.

The first step is to identify where the delay occurs rather than assuming that every slow request is caused by the connection pool.

2. Understand HTTP Connection Pooling

HTTP connection pooling allows an application to reuse previously established network connections.

Instead of creating a new TCP and TLS connection for every request, HttpClient can reuse an existing connection to the same server.

Consider the following simplified flow:

Application
    |
    v
HttpClient
    |
    v
HTTP Connection Pool
    |
    +---- Existing Connection ----> API Server
    |
    +---- Existing Connection ----> API Server
    |
    +---- New Connection ---------> API Server

When a request arrives, the HTTP handler checks whether a suitable connection is available.

• If an idle connection is available, it can be reused.

• If all available connections are busy, the request may wait.

• If a new connection is required, the handler establishes one.

Connection reuse avoids repeating DNS, TCP, and TLS setup for every request.

An important detail is that the connection pool belongs to the underlying HTTP handler, not simply to the HttpClient object.

Two HttpClient instances using different handlers generally have separate connection pools. This is why repeatedly creating clients with new handlers can defeat connection pooling.

3. Avoid Creating HttpClient for Every Request

One of the most common mistakes in .NET applications is creating and disposing HttpClient inside every service method.

For example:

public async Task<string?> GetProductAsync(int productId)
{
    using var client = new HttpClient();

    return await client.GetStringAsync(
        $"https://api.example.com/products/{productId}");
}

This approach can create a new connection pool for every invocation.

When the application receives high traffic, connections are repeatedly opened and closed. Closed TCP connections can remain in the TIME-WAIT state for some time, so ports are not necessarily available for immediate reuse.

This can contribute to socket exhaustion and connection failures.

Better approach: Reuse HttpClient

For applications that do not need multiple client configurations, a long-lived HttpClient is one option.

public class ProductService
{
    private static readonly HttpClient Client = new HttpClient();

    public async Task<string?> GetProductAsync(int productId)
    {
        return await Client.GetStringAsync(
            $"https://api.example.com/products/{productId}");
    }
}

The same client and underlying connection pool can be reused across requests.

However, a long-lived client also needs an appropriate connection lifetime strategy when DNS changes must be detected. This is where PooledConnectionLifetime becomes useful.

4. Use PooledConnectionLifetime to Handle DNS Changes

Reusing HttpClient solves unnecessary connection creation, but long-lived connections introduce another consideration: DNS changes.

Suppose an external API is hosted behind a load balancer or cloud infrastructure. Its IP address can change while the application is running.

HttpClient resolves DNS when establishing a connection. It does not continuously monitor DNS time-to-live values for an existing connection.

If the application keeps reusing an old connection indefinitely, it might continue communicating with an earlier server address.

You can configure SocketsHttpHandler with PooledConnectionLifetime:

var handler = new SocketsHttpHandler
{
    PooledConnectionLifetime = TimeSpan.FromMinutes(5)
};

var httpClient = new HttpClient(handler);

After the configured lifetime expires, a connection is no longer reused for new requests once its current activity has completed. A subsequent connection can perform a fresh DNS lookup.

The five-minute value is an example, not a universal recommendation. Choose the lifetime based on the expected DNS changes and infrastructure behavior.

This approach allows applications to benefit from connection reuse without depending on connections that remain active indefinitely.

5. Use IHttpClientFactory in ASP.NET Core

For most ASP.NET Core applications, IHttpClientFactory is a practical way to manage HttpClient instances.

It provides:

• Centralized HTTP client configuration.

• Reusable HTTP message handlers.

• Connection pool management through handler reuse.

• Named and typed clients.

• Integration with logging and resilience features.

Start by registering a named client:

builder.Services.AddHttpClient("ProductApi", client =>
{
    client.BaseAddress = new Uri("https://api.example.com/");
    client.Timeout = TimeSpan.FromSeconds(30);
});

You can then inject IHttpClientFactory into a service:

public class ProductService
{
    private readonly IHttpClientFactory _httpClientFactory;

    public ProductService(IHttpClientFactory httpClientFactory)
    {
        _httpClientFactory = httpClientFactory;
    }

    public async Task<string?> GetProductAsync(int productId)
    {
        var client = _httpClientFactory.CreateClient("ProductApi");

        return await client.GetStringAsync(
            $"products/{productId}");
    }
}

Each call to CreateClient returns a new HttpClient instance, but the factory manages and pools the underlying handlers.

This is an important distinction. Creating a client through IHttpClientFactory does not mean creating a completely new connection pool every time.

Configure the handler lifetime

You can also configure how long the factory keeps a handler in its pool:

builder.Services
    .AddHttpClient("ProductApi", client =>
    {
        client.BaseAddress = new Uri("https://api.example.com/");
    })
    .SetHandlerLifetime(TimeSpan.FromMinutes(5));

The handler lifetime and PooledConnectionLifetime solve related but different problems.