Default connection limit has a long history. The Default connection limit has been much higher since asp.net 4.0 in where it was updated to 12*number of threads. In 4.6.1 and higher it is auto configuration for you to MaxInt (https://referencesource.microsoft.com/#System.Web/HttpRuntime.cs,1200). Given the long history of the value changing from one framework to another (and if you on different platform you will get the default value of 2) it is recommended to manually set it so you have have control, even if you set it to MaxInt.
If you want to modify it to something that is different there are some articles here on what changes it affects: https://docs.microsoft.com/en-us/dotnet/framework/network-programming/managing-connections A good article for grasping the implications of modifing that value is: https://docs.microsoft.com/en-us/archive/blogs/jpsanders/understanding-maxservicepointidletime-and-defaultconnectionlimit
In addition, it is suggested to look at a few more settings (you will need to consider if they are appropriate for you use cases):
- if your messages are really small turning
UseNagleAlgorithm = falsecan get higher throughput for services with small messages (https://docs.microsoft.com/en-us/dotnet/api/system.net.servicepointmanager.usenaglealgorithm?view=netframework-4.8) - setting
Expect100Continue=false: for calls every POST will do two requests to try and save sending the body to the server in the first request and then the HTTP server has to respond and say "go ahead and send it": https://docs.microsoft.com/en-us/dotnet/api/system.net.servicepointmanager.expect100continue?view=netframework-4.8
Although related to using the storage apis there is good info here on the affect of those other values: https://social.msdn.microsoft.com/Forums/en-US/d84ba34b-b0e0-4961-a167-bbe7618beb83/net-and-adonet-data-service-performance-tips-for-windows-azure-tables?forum=windowsazuredata