webapi c＃用异步等待加载测试结果令人费解

Question

我们正在对我们的一个网络API端点进行负载测试，我们无法相信我们看到的结果。

在方案1中，我们的tps（每秒吞吐量）为~1 /秒，而在方案2中，我们的tps为~3 /秒。我们预计情景1中的tps高于2。

场景1是我们当前称为服务1的系统。场景2是我们在中间引入桥接服务以组合服务1和服务2的结果的新系统。因此，场景2的吞吐量应低于方案1，因为在方案1中我们直接调用我们的服务1。

所有服务都在web api asp.net 4.5中。服务1和2没有异步等待操作。 Bridge Service具有异步等待操作并同时调用服务1和2，并等待两个调用完成。呼叫服务1总是比呼叫服务2更长。因此，服务1决定总呼叫时间。服务器是Windows Server 2012 R2和IIS 8.桥接服务和服务1部署在同一服务器上，并且位于同一应用程序池中。服务2部署在另一台服务器上。

此外，我们验证了我们在两种情况下都对服务1进行了完全相同的调用。

我们在JMeter和soap ui中看到了相同的结果。

以下是桥接服务的代码：

Answer 1

显然，我们对服务1的呼叫在两种情况下都不一样。当我们直接调用服务1时，我们在cookie中传递ASP.NetSessionId，但是当网桥调用服务1时，它没有传递cookie中的会话ID。

判决： 在我们最初的负载测试中，我们使用了一个ASP.NetSessionId，而asp.net有一些会话级锁，因此降低了性能。

因此，为了测试会话级锁定理论，我们通过模拟50个用户而不是1个用户来进行负载测试，这次性能与桥接器相当。