HttpWebRequest Port Exhaustion

Question

We use the Windows service to access the internal REST service very often (20-40 calls per second), but pay attention to the long delay in receiving responses after the service starts for several minutes.

Looking at netstat, there are quite a few ports with the status "TIME_WAIT", and it looks like we may have a shortage of ports.

How can we guarantee that ports will be reused?

Answer 1

There is a limit on the number of concurrent outgoing HTTP connections. You can control this using the static property System.Net.ServicePointManager.DefaultConnectionLimit before creating HttpWebRequest objects

It might be worth setting this higher than the default, which in my opinion is 2.

If this does not help, you can also increase the default size of ThreadPool so that you can create queries faster. The thread pool only gradually increases the number of threads - a new thread for every half second, IIRC

Answer 2

This is probably due to the same problem that many users face when using the HttpClient class and classes that use HttpClient internally. As a result of the implementation of the HttpClient of the IDisposable interface, you will find that many developers want to wrap any new class instances in a using statement. There is only one problem with this; When the HttpClient object is removed from the connected ports, they remain blocked for 5 minutes "TIME_WAIT" until they are released by the OS.

I usually use one instance of HttpClient (singleton) and use fully qualified URLs in combination with asynchronous calls.

Answer 3

How can we guarantee that ports will be reused? Do not set the connection limit to a value that almost guarantees that they will not.

It seems like at some point someone is monkey with ServicePointManager. I would restrict ServicePoint to this source: encourage pipelining and reuse of http:

 ServicePointManager.FindServicePoint(Uri).ConnectionLimit = someSensibleValue;