Q:

Rapid web requests to many different websites using HttpClient C#

My team maintains a tool that is responsible for doing rapid verification of over 1000 different client websites.   The tool is a Windows Service (.NET 4.5.2, C#) that reads requests from a queue, and executes a 'health check' for each request.   It usually handles over 500 requests a minute, but can be responsible for more.   Each request takes a second or two to execute. 
A request contains a Uri and credentials needed for doing the health check.   A health check is a POST against the AUTH page with the credentials (the app has custom auth, it's not header based auth), and then a GET to the home page, with a quick verification that it's the home page we expect.   It then goes to a status page in the application, and does some quick checks against that.   The GET requests have to use the cookies from the Set-Cookie header in the auth post. 
We've been having performance problems with the tool as it scales.   It currently creates a new HttpWebRequest object for each post and get in the process.   There is a shared CookieContainer that is populated by the first post, so that we can get to the home page and then the status page. 
I want to change this service to use the HttpClient object available in .NET 4.5.   The problem is everywhere I read online says you want to avoid rapid creation and destruction of HttpClients.   You'd rather keep one instance alive for the lifetime of the application.   The problem I have is that HttpClient seems to work really well against one endpoint, not many. 
I have looked into several options, and am not sure which is best to proceed:

Create a new HttpClient for each request, and use it for the duration of that request.   That means it will live for a couple seconds, and be used for 3 calls.   This would not be easy to implement, but I'm concerned about the overhead of creating and destroying hundreds of HttpClients a minute. 
Figure out if it's possible to use one HttpClient instance for different endpoints by avoiding usage of a BaseAddress, and using the client to pass HttpRequestMessages using SendAsync.   I haven't been able to figure out cookies with this method yet.   To avoid having the HttpClient store the cookies, I set UseCookies to false in the HttpClientHandler, and tried managing cookies via headers in the HttpRequest/ResponseMessages themselves, but it looks like HttpClient simply strips cookies when UseCookies is set to false, so I was unable to pass cookies between request.  edit: cookies work fine because they are stored per domain. 
Store several hundred different HttpClient instances in some sort of dictionary, and pull the appropriate one for each Uri as the requests come in.   I'm not sure about the memory overhead on this though.   Also each unique Uri is only verified once every 5 minutes, so I'm not sure if having an HttpClient used once every 5 minutes keeps an unnecessary number of ports open. 
Keep using HttpWebRequests.   Maybe this older method still performs better in this situation. 

If anyone has faced a similar issue, I'd love some input on where to proceed on this. 
Thanks! 

A:

The problem with creating new HttpClients for each request is that HttpClientHandler will close the underlying TCP/IP connection.   However, if you are using each HttpClient for the 3 requests to one host and then hitting a different host, then keeping the connection open doesn't help when you move to a new host.   So, you probably will not see perf problem with one client per host.   HttpClient itself is a very lightweight object.   It isn't going to cost much to create one. 
However, HttpClient simply delegates the real work to HttpClientHandler which uses HttpWebRequest under the covers, therefore will be unlikely to have any better performance than directly using HttpWebRequest. 
If you are looking for better performance, then I suggest looking into replacing HttpClientHandler with the new WinHttpHandler which bypasses HttpWebRequest and goes directly to the Win32 API to make calls. 
The full source is available for WinHttpHandler on GitHub so you can see exactly how it handles cookies and credentials. 
And I would be really interested to hear if you do get much better perf with WinHttpHandler.