1

I'm load/stress testing using Visual Studios load testing project with current users set quite low at 10. The application makes multiple System.Net.Http.HttpClient request to a WebAPI service layer/application (which in some cases calls another WebApi layer/application) and it's only getting around 30 request/second when testing a single MVC4 controller (not parsing dependent requests).

These figures are based on a sample project where no real code is executed at any of the layers other then HttpClient calls and to contruct a new collection of Models to return (so some serialization happening too as part of WebApi). I've tried both with async controller and without and the results seemed pretty similar (slight improvement with async controllers)

Caching the calls obviously increases it dramatically (to around 400 RPS) although the nature of the data and the traffic means that a significant amount of the calls wouldn't be cached in real world scenarios.

Is HttpClient (or HTTP layer in general) simply too expensive or are there some ideas you have around getting higher throughput?

It might be worth noting that on my local development machine this load test also maxes out the CPU. Any ideas or suggestions would be very much appreciated?

Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
Timmo
  • 11
  • 1
  • 2
  • It's really hard to provide constructive feedback when there's so many variables involved. Are your services running all on the same machine, different machines, how many networks hops are made, are you crossing domains, etc? There could be lots of latency in your requests since you're talking about calling Web API services that could call other Web API services. – David Hoerster Feb 10 '14 at 22:56
  • I've seen HttpClient doing 12000 reqs/sec against a local web api on a dev machine. However there are a ton of factors to consider. HttpClient should not be adding a lot of overhead. – Darrel Miller Feb 11 '14 at 04:22
  • The sample app includes all the tiers within one application all running locally on my development machine. It's promising to hear you've seen 12000 HttpClients req/sec though. – Timmo Feb 17 '14 at 00:41

2 Answers2

2

HttpClient has a built-in default of 2 concurrent connections.

Have you changed the default?

See this answer

I believe if you chase the deps for HTTPClient, you will find that it relies on the settings for ServicePointManager.

See this link

You can change the default connection limit by calling System.Net.ServicePointManager.DefaultConnectionLimit

Community
  • 1
  • 1
CtrlDot
  • 2,463
  • 14
  • 11
  • In some scenarios you have to explicitly set the DefaultConnectionLimit for it to have an effect with HttpClient. My experience has been unless you set it, you will see an unlimited number of connections and that can actually make your performance far worse. – Darrel Miller Feb 11 '14 at 04:25
  • Could you define those scenarios? I've have always seen the 2 connection default enforced... – CtrlDot Feb 11 '14 at 16:03
  • Try using httpclient from a console app. – Darrel Miller Feb 11 '14 at 16:26
  • I was under the impression the limits did not apply calls to localhost ? Perhaps I should have been more clear that all tiers are currently within a simple single sample app all running locally. – Timmo Feb 17 '14 at 00:44
  • See this link https://stackoverflow.com/questions/5760403/what-to-set-servicepointmanager-defaultconnectionlimit-to – kumar chandraketu Sep 17 '18 at 20:50
1

You can increase number of concurrent connection for http client. Default connection limit is 2. In order to find optimum connection try the formula 12* number of CPU on your machine.

In code : In code: 

ServicePointManager.DefaultConnectionLimit = 48;

Or In Api.config or web.config file 

<system.net>
    <connectionManagement>
      <add address="*" maxconnection="48"/>
    </connectionManagement>
  </system.net>

Check this link for more detail.

kumar chandraketu
  • 2,232
  • 2
  • 20
  • 25