At a first glance when coding ASP.NET Core 3.1 applications, one might think that as long as you can handle all incoming requests, a bunch of outgoing requests will be made concurrently to other API's and such (assuming that your API is making a lot of outgoing API calls of course).
I'm wondering about this, because when I read the docs about how many calls are actually made, I stumble upon the ServicePointManager and it's property DefaultConnectionLimit. The default value seem to be 10 according to docs:
The maximum number of concurrent connections allowed by a ServicePoint object. The default connection limit is 10 for ASP.NET hosted applications and 2 for all others.
This ServicePointManager is used by HttpClient for example, so even if you processes 1k incoming requests/second, the number of outgoing requests through HttpClient will never be more than 10 at any given time. And this is what I don't understand - how can this possibly scale well? My naive way of thinking was that of course, .NET Core itself doesn't limit the number of outgoing requests, and it will be up to you if your API exhausts other API's by nuking requests, but apparently this will never happen out of the box, since the ServicePointManager by defaults prohibits this.
I've seen examples that "recommends" to call ServicePointManager.DefaultConnectionLimit = int.MaxValue at startup.
But why is it set to such a low value as 10 in the first place? And is it reasonable to set it to int.MaxValue?
