HttpClient single instance or multiple

Recently, we were working on a project that needed numerous HTTP requests to be made. Initial implementation had a new HttpClient object being created for every request being made. It looked to have some performance cost attached to it that led us to evaluate the effect of using single vs multiple instances of HttpClient.

Problem Statement:

Whats the best way to use HttpClient for multiple requests and the performance cost associated with it?

Assessment:

Went through the Microsoft documentation, which seemed updated based on last when I read few years back. Found a fineprint for myself that states:

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.

This was a straight give away that we should use a single instance HttpClient – irrespective of a usecase, one would want to keep distance from SocketException errors (though probability of it would be high for heavy usage of HTTP requests).

Now, the query was how to have single HttpClient for multiple requests but with different request payload for the calls? Also, does this has any impact on performance of the calls and if so, how much?

Resolution:

I started with looking into performance aspect for the two options. Created a test application that helped evaluate the time taken for various number of requests. Tried with www.google.com but seems they have some kind of check at 1000 requests so went ahead with www.bing.com that looked uniform till 5000 requests that I tried with.

for (var i = 0; i < noOfConnections; i++)
{
    using (var httpClient = new HttpClient())
    {
        var result = httpClient.GetAsync(new Uri("http://www.bing.com/")).Result;
    }
}
//having private static readonly HttpClient _httpClient = new HttpClient();
for (var i = 0; i < noOfConnections; i++)
{
    var result = _httpClient.GetAsync(new Uri("http://www.bing.com/")).Result;
}

With the above, I got the following numbers on an average post few runs:

No of RequestsMultiple Instance (s)Single Instance (s)%age Diff
1002016.6716.65
5001038814.56
100021617419.44
200043035118.37
5000103290612.21

It looked like the difference peaked around 1000 requests and overall there was an improvement with single instance.

Now, given we had a usecase where multiple HTTP requests has to be made simultaneously but with different payloads, looked at how to achieve it with single instance. Keeping multiple types of requests, unit testing, high load – One possible way looked like below that worked out well for us:

// Single instance of HttpClientManager was setup
public class HttpClientManager : IHttpClientManager
{
    ...
    public HttpClientManager(HttpMessageHandler messageHandler)
    {
        _httpClient = new HttpClient(messageHandler);
    }
    private HttpRequestMessage SetupRequest(IRequestPayload requestPayload)
    {
        var request = new HttpRequestMessage
        {
            RequestUri = new Uri(requestPayload.Url)
        };
        switch (requestPayload.RequestType)
        {
            case RequestType.POST_ASYNC:
                request.Method = HttpMethod.Post;
                request.Content = GetHttpContent(requestPayload.ContentJson);
                break;
            case RequestType.PUT_ASYNC:
                request.Method = HttpMethod.Put;
                request.Content = GetHttpContent(requestPayload.ContentJson);
                break;
            case RequestType.DELETE_ASYNC:
                request.Method = HttpMethod.Delete;
                break;
            case RequestType.GET_ASYNC:
                request.Method = HttpMethod.Get;
                break;
            default:
                request.Method = HttpMethod.Get;
                break;
        }
        ...
    }
    public HttpResponseMessage ExecuteRequest(IRequestPayload requestPayload)
    {
        HttpRequestMessage httpRequestMessage = SetupRequest(requestPayload);
        HttpResponseMessage httpResponseMessage = _httpClient.SendAsync(httpRequestMessage, HttpCompletionOption.ResponseHeadersRead).Result;
        return httpResponseMessage;
    }
    private HttpContent GetHttpContent(string contentJson)
    {
        return new StringContent(contentJson, ENCODING, MEDIATYPE_JSON);
    }
}

Since there are numerous articles on the web explaining details of the entire HttpClient workflow and inner details, I will not cover that here but a quick explanation on couple of key info. In the code above:

HttpRequestMessage is used to setup HttpClient object based on our need. We make use of the fact that HttpRequestMessage can be used only once. After the request is sent, it is disposed immediately to ensure that any associated Content object is disposed.

Making use of HttpClient underlying implementation, have used HttpMessageHandler more from the unit test point of view.

Conclusion:

One should use a single instance of HttpClient at application level to avoid create/destroy of it multiple times. Further, results suggest this also has better performance with more than 12% improvement based on the load.

For multiple requests of different payloads, having a single instance HttpClient but a new HttpRequestMessage for every request looked a good approach to use.

P.S.: For .NET Core, Microsoft added a new interface around the same discussion to have better handle at HttpClient instance: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests

Entire code for lookup can be downloaded from here.

HTML5: Tips !!!

Long time, since I have blogged. Specifically, this particular post – had all the details and wanted to post more than a year back. I guess, better late than never!
Here are few of the HTML5 tips that might help while using it’s various features:

HTML5 WebSocket Protocol is present only from IIS 8.0

HTML5 Web Socket provides a two-way communication over one TCP connection (socket). IIS 8.0 (ships with Windows 8) is capable of accepting Web Socket communications. In order to use the new protocol, one has to enable it in IIS 8.0, using option “Turn Windows features on or off” present in the control panel. It should look like below:
WebSocketIIS8
A quick detail on how WebSocket works can be looked here in my article: http://www.codeproject.com/Articles/546960/HTML-Quick-Start-Web-Application#websocket
 

One can support new HTML5 elements in older browsers using HTML5 shiv

Older browsers that are still widely used by end users (namely IE6/7/8) do not have support for the new elements in HTML5. One great way to enable HTML5 element support in IE6/7/8 is to have the http://code.google.com/p/html5shiv/
As noted on the linked Google page, “shiv” and “shim” are interchangeable terms in this context.
In case interested, I came across a good sample example and details out here: http://www.sitepoint.com/html5-older-browsers-and-the-shiv/
 

Elements in HTML5 can easily be made draggable

The specifications defines an event-based mechanism – a JavaScript API and additional markup for declaring it. Any type of element can be marked draggable on a page. It’s a known fact that having a native browser support for a particular feature is best as they would be faster and provide a more responsive application.
A quick detail about the feature can be read here: http://www.codeproject.com/Articles/546960/HTML-Quick-Start-Web-Application#dragdrop
 

‘Type’ attribute for script and link are no more required in HTML5

Type attribute is optional and one does not need to provide it for script and link tag in HTML5.
Earlier, one used to give:

<link rel="stylesheet" href="somepath/somestylesheet.css" type="text/css" />
<script type="text/javascript" src="somepath/somescript.js" />

Now, in HTML5, same references can be provided as:

<link rel="stylesheet" href="somepath/somestylesheet.css" />
<script src="somepath/somescript.js" />

This makes things simpler as the file extension and the tag were enough to interpret the type.
 

async attribute has been added to <script> tag in HTML5

HTML5 has added a new attribute for <script> tag, which is async. With this attribute, the external script will be executed asynchronously as soon as it is available. It has no effect on inline scripts.
Inline scripts and scripts without async or defer attributes are fetched and executed immediately, before the browser continues to parse the page.
 

In HMTL5, all unknown element in all browsers are displayed inline by default

The three most commonly used values are none, block, and inline. All elements have an initial or default state for their display value.For all HTML5 elements, by default they have a computed display value of inline.
 

In HTML5, page and worker do not share the same instance

In HTML5, page and worker do not share the same instance – a duplicate is created on each pass. Data passed between the main page and workers are copied. Objects are serialized as they’re handed to the worker, and subsequently, deserialized on the other end. I read that most browsers implement this feature as structured cloning. (The structured clone algorithm is a new algorithm defined by the HTML5 specification for serializing complex JavaScript objects.)
A quick detail about the feature can be read here: http://www.codeproject.com/Articles/546960/HTML-Quick-Start-Web-Application#webworkers
 

In HMTL5 Offline, relative URLs listed in a manifest are resolved relative to the manifest file

Yes, the urls in the manifest are relative to manifest’s own url. It is not to be confused that they are relative to root. Though it might happen that the urls relative to root work good because the manifest file might be located in the application root.
A quick detail about the feature can be read here: http://www.codeproject.com/Articles/546960/HTML-Quick-Start-Web-Application#offlineapp

HTML5 Quick Start Web Application

HTML5 Quick Start


I was learning HTML5 features since December. While going through it, I was playing around making a sample web application fully HTML5 enabled – kind of self learning kit that would give a basic knowledge to anyone who goes through it. Plan was to publish it as an article so that others can learn quickly and have basic features at one place. One can play around with the feature implementation straight away post download.

It took me some time to write the article as it covered good number of features. I finished working on it and have published it today on CodeProject: HTML5 Quick Start Web Application

One can have a look at it there and provide feedback.

UPDATE: Missed uploading this to Github earlier, uploaded here: https://github.com/sandeep-mewara/HTML5QuickStart

Keep learning!