Lind. DDD. Utils. HttpHelper for correct use of HttpClient, httpclient

Lind. DDD. Utils. HttpHelper for correct use of HttpClient, httpclient

Back to directory

The official website is not necessarily right. Machines can prove everything best.

I don't know when we will get used to adding using when writing database connections, network connections, and file operations. This kind of habit is called a pattern by mistake, but in fact, everything is successful. What is the role of using? I think everyone knows that it can release resources, but for database connections, it is not just to release data connections, but to put the connections in the "connection pool", waiting for the next use, it can be obtained directly from the pool. The advantage is that it saves a lot of overhead for "establishing connections", but not for network connections, it is not that simple and cannot be used together, this is also an incorrect description and Writing Method for MSDN. Recently, when I was reading a blog post (translated by Infoq, a foreigner), I provided favorable evidence. For more information, see the following.

Using is actually the implementation of the IDispose module.

  using (var http = new HttpClient(handler))   {    http.Timeout = new TimeSpan(0, 0, timeOut);    HttpResponseMessage response;    response = http.GetAsync(GeneratorUri(requestUri, ApiValidateHelper.GenerateCipherText(nv))).Result;    return response;   }

The above code is also recommended by MSDN, that is, it is automatically released after network resources are used, and the next access to network resources needs to be built again. In fact, from the destruction of resources to the establishment of the next resource, it takes a lot of money, and the construction of your network connection (socket) is limited, not infinitely close, so, we must control it.

Http://www.infoq.com/cn/news/2016/09/HttpClient:

Http://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/:

The following is a test conducted by uncle on the using method. We can see that there are many TCP connections. In this way, when high concurrency occurs, your socket connection will be used.

When the available socket is exhausted, this exception may occur: System. Net. Sockets. SocketException!

Improved Program (single-instance or static HttpClient)

Readonly static HttpClient http = new HttpClient (new HttpClientHandler () {AutomaticDecompression = System. net. decompressionMethods. GZip}); [TestMethod] public void Get () {Stopwatch sw = new Stopwatch (); sw. restart (); for (int I = 0; I <1000; I ++) {var response = http. getAsync ("http://www.sina.com "). result;} sw. stop (); Console. writeLine ("1000 request time" + sw. elapsedMilliseconds );}

After the modification, we can see that the test performance of the entire HttpClient has been significantly improved!

For the TCP connection output on the console, we only see one piece of relevant data. This is what we want to see!

netstat -nbp | findstr 202.108.33.107

Result

Finally, I would like to thank Infoq for editing Xie Li for finding such a good article!

Back to directory