46

ASP.Net HttpClient is disposable, and a lot of articles say you should use the singleton pattern to use it because of the performance. But when I see the RestClient it can't be disposed, and in the Recommended-Usage page the sample will new the RestClient every time. Should I use singleton pattern for RestClient or should I new it every time? If I new it every time will there be any performance concern?

RestSharp GitHub

Some references:

Do HttpClient and HttpClientHandler have to be disposed

YOU'RE USING HTTPCLIENT WRONG AND IT IS DESTABILIZING YOUR SOFTWARE

MichaelMao
  • 2,596
  • 2
  • 23
  • 54

2 Answers2

71

For Restclient version < 107:

should I use singleton pattern for RestClient or should I new it everytime, if I new it everytime will any performance concern?

Recommended way to use RestSharp is to create a new instance per request.

It differs from Singleton approach recommended for HttpClient. And the reason is that under the hood RestSharp uses HttpWebRequest for HTTP interaction, not HttpClient. That's why the usage model differs.

If I create it everytime do I get performance issue just like the HttpClient?

The main reason why you shouldn't create a new instance of HttpClient for each request is not a performance consideration. The time spent for creation and initialization will take a tiny fraction of time spent for following network call. The main reason to use singleton instance of HttpClient is the following:

HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors.

RestSharp does not use connection pool as HttpClient and does not leave opened sockets after the use. That's why it is safe (and recommended) to create a new instance of RestClient per request.

Will you gain any performance improvement if you use reuse instance of RestClient? Well, you will save the time for creation of object and its initialization. However this time is very close to 0 and moreover it's a tiny fraction of time spent for following network call. You don't reuse other .NET objects like List<T> because of performance considerations, are you? You should do the same for RestClient. It's just developed in a way that implies such usage scenario.

unhammer
  • 4,306
  • 2
  • 39
  • 52
CodeFuller
  • 30,317
  • 3
  • 63
  • 79
  • 1
    If I create it everytime do I get performance issue just like the `HttpClient`? – MichaelMao Apr 01 '18 at 02:21
  • I update my post please see the references and I think you are right – MichaelMao Apr 02 '18 at 01:40
  • 2
    After reading this answer I'm wondering if it would make sense to inject `IRestClient` as a transient to WebApi services? – Reboot_87 Jul 24 '19 at 11:27
  • 1
    Yes, it totally makes sense. – CodeFuller Jul 24 '19 at 13:54
  • 3
    Not sure if this is accurate anymore, I was about to implement restsharp in a project but pumped the brakes because it appears to use a new socket on each request, this would likely cause socket exhaustion at any scal. github.com/restsharp/RestSharp/issues/1322 – StuckOverflow Aug 14 '20 at 20:09
  • We were using rest sharp and would routinely get socket exception errors using the new each time. – Justin Oct 09 '20 at 22:23
  • I agree that the answer is misleading. thanks @StuckOverflow for pointing me to the link. I had a back and forth with my team mate about this, who after googling suggested we stick to restsharp. but having read the latest update from restharp on github, i realise that it might not be ideal for apps t hat make several http requests this may not be ideal as instantiating it everytime could lead to socket exhaustion. https://github.com/restsharp/RestSharp/issues/1406 confirms that the dev has plans to do this later but it is opensource after all. – Eakan Gopalakrishnan Feb 06 '21 at 19:54
  • 5
    just to give you further information, HttpWebRequest instantiates HttpClient everytime it is instantiated, leading to the socket exhaustion detailed by microsoft docs. Since RestSharp's RestClient, uses HttpWebRequest, instantiating RestClient, multiple times in different parts of the app, would lead to the same socket exhaustion. code can be seen here: https://github.com/dotnet/corefx/blob/07080ceab1e5b305d8a5fecd9d5b793fb502d57a/src/System.Net.Requests/src/System/Net/HttpWebRequest.cs#L1101 – Eakan Gopalakrishnan Feb 06 '21 at 20:00
  • 1
    HttpWebRequest has GetCachedOrCreateHttpClient function that will use AreParametersAcceptableForCaching to check if HttpClient can be reused – volody Jul 09 '21 at 14:26
  • 6
    The pattern changed with version v107 https://restsharp.dev/v107/#restsharp-v107 Do not instantiate the client for a single call, otherwise you get issues with hanging connections and connection pooling won't be possible. – MorioBoncz Mar 26 '22 at 18:25
18

For Restclient version >= 107:

From version v107 you should create only one instance. This version is using HttpClient internally.

Do not instantiate RestClient for each HTTP call. RestSharp creates a new instance of HttpClient internally, and you will get lots of hanging connections, and eventually exhaust the connection pool.

If you use a dependency-injection container, register your API client as a singleton.

RestClient lifecycle

If you are wondering why this is the case, you can see explanation here

unhammer
  • 4,306
  • 2
  • 39
  • 52
titol
  • 999
  • 13
  • 25