Am I safe from thread pool starvation/socket issues if I use Flurl in a service thats registered as Transient?

Question

Let's say I have a simple service that's registered as a Transient in Startup , and I use Flurl like so:

public async Task DoStuff()
    {
        string url = "some valid Url";
        await url
            .AppendPathSegment("notifications")
            .WithHeader("a header", headervalue1)
            .WithHeader("another header", headervalue2)
            .PostJsonAsync(data);
    }

This service will be used a lot throughout our app. Can I count on Flurl to handle the requests efficiently so that my app doesn't exhaust the number of sockets available under heavy loads?

Answer 1

According to their docs : yes - the default usage, as you are showing, makes uses of the implementation guidelines provided by Microsoft :

Quote:

Flurl.Http is built on top of the System.Net.Http stack. If you're familiar with HttpClient, you probably already know this advice :

HttpClient is intended to be instantiated once and re-used throughout the life of an application. Especially in server applications, creating a new HttpClient instance for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors.

Flurl.Http adheres to this guidance by default. Fluent methods like this will create an HttpClient lazily, cache it, and reuse it for every call to the same host*:

Sources:

https://flurl.dev/docs/client-lifetime/

https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=net-6.0#remarks