webapi C＃使用异步等待令人费解的负载测试结果

Question

We are doing a load test on one of our web api end point and we can't believe the results that we are seeing.

In scenario 1 our tps (throughput per second) is ~1/sec while in scenario 2 our tps is ~3/sec. We expected a higher tps in scenario 1 than in 2.

Scenario 1 is our current system where we call service 1. Scenario 2 is the new system where we are introducing a bridge service in the middle to combine results from service 1 and service 2. Hence, scenario 2 should have lower throughput than scenario 1, because in scenario 1 we are directly calling our service 1.

All the services are in web api asp.net 4.5. Service 1 and 2 does not have async await operations. Bridge Service has async await operations and makes call to service 1 and 2 at the same time and waits for both the calls to finish. Call to service 1 always take longer than call to service 2. Hence, service 1 decides the total call time. The server is windows server 2012 R2 and IIS 8. Bridge service and Service 1 are deployed on the same server and are in the same application pool. Service 2 is deployed on another server.

Also, we verified that we are making the exact same call to Service 1 in both the scenarios.

We are seeing the same results in JMeter and soap ui.

Following is the code from bridge service:

Answer 1

Apparently our call to service 1 wasn't same in both the scenarios. When we call service 1 directly we pass the ASP.NetSessionId in the cookie, but when the bridge called the service 1 it didn't pass the session id in the cookie.

Verdict: In our original load test we used one ASP.NetSessionId and asp.net has some session level locks, hence it reduced the performance.

Hence, to test the session level lock theory, we did a load test by simulating 50 users instead of 1 user, and this time the performance is on par with bridge.