0

I am attempting to stress test my service. To do that I call

await client.PostAsync(url, content);

Normal calls that go through there work just fine. But when I hit it hard, the client call above (to post to the service) starts to fail.

At first it starts to give this error:

System.Threading.Tasks.TaskCanceledException: A task was canceled.

It also will give this error:

System.Net.Sockets.SocketException (10055): An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.

Then after short time, the errors change to:

System.Net.Sockets.SocketException (10048): Only one usage of each socket address (protocol/network address/port) is normally permitted.

My code is part of a NuGet package that will run in normal .Net Framework applications (WCF, WPF, ASP.NET etc) and the newer ASP.Net Core 3.1.

Because of that I don't really have easy access to the .Net Core DI framework. (I don't really want to make it for the normal .Net Framework and I don't want to make another instance of DI for the ASP.NET Core 3.1 apps.)

So I create my HttpClient like this.

private static readonly HttpClient client = new HttpClient{Timeout = TimeSpan.FromSeconds(25)};

Is there some other configuration I need to setup to all my HttpClient to handle a lot of very fast calls (approx 250,000 as fast as it can go)?

Or is there some way to detect that the HttpClient is saturated and wait until it is in a better state?

Vaccano
  • 78,325
  • 149
  • 468
  • 850
  • Your package can be DI friendly by providing another constructor that accepts an `HttpClient`. – Aluan Haddad Aug 10 '20 at 23:57
  • `But when I hit it hard, it starts to fail.` Which bit starts to fail? The server side (the bit being hit)? Or the client side (the bit doing the hitting)? – mjwills Aug 11 '20 at 00:05
  • 1
    Please share a [mcve] (of client and server). – mjwills Aug 11 '20 at 00:07
  • @mjwills - I updated my question to clarify that it his the client side (doing the hitting) that is failing under the load of so many requests to send out. – Vaccano Aug 11 '20 at 00:07
  • 1
    We'll need to see a [mcve] - my guess is you aren't disposing a stream somewhere. – mjwills Aug 11 '20 at 00:09
  • @mjwills - While I can (and will) build a reproducible example if needed, it will take a few hours to get it all built out. I think I will first wait for a little while to see if someone has a "Oh, you just to to change this" kind of answer. – Vaccano Aug 11 '20 at 00:10
  • `My code is part of a NuGet package that will run in normal .Net Framework applications` For .NET Framework, not Core, read https://stackoverflow.com/a/48785949/34092 . – mjwills Aug 11 '20 at 00:11
  • 3
    Are you trying to see if your client computer can make 250.000 requests **at the same time**? If you don't allow the requests to complete and release resources, eventually you will run out of local resources in various places, that is entirely correct. – Lasse V. Karlsen Aug 11 '20 at 00:13
  • @LasseV.Karlsen - Not at the exact same time. I fill up a queue as fast as I can for 1 full second with calls to make to the service. Then the queue empties as fast as it can making calls to the service. In a second it can create 250,000 requests. It takes quite a bit longer to call the service with all the requests. However, it is erroring out while sending the requests to the server (the 3 types of errors are posted in my question above). – Vaccano Aug 11 '20 at 00:20
  • 1
    You're issuing too many requests at the same time, there are no ports left for new sockets. See duplicate. You can't really detect this situation, other than catching these exceptions and implement a backoff. – CodeCaster Aug 11 '20 at 00:25
  • Even if you could detect the low resources on the local machine, that many requests could easily run afoul of a proxy or firewall, not just by exhausting resources but also by tripping DoS attack detection. – John Wu Aug 11 '20 at 00:42
  • @JohnWu - Good point. In my situation, I am calling from inside my firewall to a service that is also inside my firewall. (We did have some proxy issues at first before we configured it to allow the calls through.) – Vaccano Aug 11 '20 at 00:44

0 Answers0