Watch out for HttpWebRequest on .NET Core

TLDR; Don’t use HttpWebRequest on .NET Core in high load environments.

In .NET Framework, before 4.5 if you wanted to make a web request, you would use HttpWebRequest.Create(). In 4.5, Microsoft introduced HttpClient, a new class that was same same, but different. I don’t explain the differences here.

HttpWebRequest used WinHttp because it always ran on Windows. In .NET Core, WinHttp doesn’t exist outside of Windows (it still uses it on Windows) but if you run on Linux, you’re going to be using libcurl.

The recommended way (I think) in making HTTP requests now is to use, HttpClient. HttpClient is designed NOT to be a short lived, when you instantiate a new instance of HttpClient, it creates its own connection pool which is not shared with other instances of HttpClient.

In .NET Core now, if you use HttpWebRequest (which exists), the underlying logic instantiates a new instance of HttpClient. HttpWebRequest was initially designed to be used once, you could not call Create() to return an object and then reuse it.

In an environment where you need to make many requests to a resource where you are using HttpWebRequest.Create(), you may find yourself getting exceptions related to exhausted resources.

This is occurring because HttpWebRequest initiates a new instance of HttpClient each time, which prevents any existing sockets being shared. You’re then waiting for the natural cleaning process to occur. If you’re requesting many resources a second, you’ll quickly exhaust the pool and run out of available ports to create with a socket.

Keep a HttpClient instance as long lived as possible.

Comments