我正试图在我没有构建的应用程序中确定负载下的性能问题，但是已经非常熟悉它的工作原理。
架构是：移动应用程序调用ASP.NET MVC 3网站以获取要显示的数据。 ASP.NET站点使用WCF客户端（basicHttpBinding）调用第三方SOAP API，尽可能地缓存结果以最小化第三方的负载。
移动应用程序的负载在高峰时间大约为每秒200多个请求，这意味着在缓存之后，每秒向第三方提供20个SOAP请求。
通常它运行正常，但是我们得到级联缓慢的时段，其中API的每个请求开始花费5秒......然后10 .. 15 .. 20 .. 25 .. 30 ..此时它们超时（我们将WCF客户端超时设置为30秒）。显然，某个地方存在一个瓶颈，导致队列越来越长，直到请求在30秒内无法提供服务。
现在，第三方API不受我的控制，但他们发誓，每秒20个请求不应该出现任何问题。所以我一直在研究我的瓶颈可能性。
我已经在StackOverflow上阅读了关于ServicePointManager.DefaultConnectionLimit和connectionManagement的问题，但是从源头上挖掘，我认为问题更为根本。似乎我们的WCF客户端对象（由“添加服务引用”自动生成的标准System.ServiceModel.ClientBase<T>）存储在缓存中，因此当多个请求同时进入ASP.NET站点时，它们将共享一个客户端对象。
通过对几个控制台应用程序的快速实验并生成多个线程来调用具有共享Client对象的故意慢速WCF服务，在我看来，当多个线程使用单个ClientBase时，只会发生一次调用。这可以解释一个瓶颈，例如每秒需要进行20次呼叫，每次呼叫需要50多秒才能完成。
有人能证实确实如此吗？
如果是这样，如果我切换到创建它自己的WCF客户端对象的每个请求，我只需要在创建客户端之前将ServicePointManager.DefaultConnectionLimit更改为大于默认值（我认为是2？）的内容对象，以增加我的最大同时连接数？
（抱歉这个冗长的问题，我认为太多的信息比太少更好）