经常有其他 BU 的同事报出服务端执行时间很短，但是客户端整个调用时间很长甚至超时的情况，具体可以分为三类：
请求在发送出去之前耗时很长
这种情况一般属于客户端并发连接数不够，导致请求在客户端排队，（参考文档：.NET 配置 HTTP 最大并发连接数）
一般表现为请求发起的时间到开始序列化请求的时间差较长，从 CAT 中看就是 SOA2Client 和 SOA2Client.serialization 之间的时间差较大。

请求在发送出去以后，在服务端开始执行之前耗时很长 （这两者中间包含了 网络传输的时间 和 Web容器调度的时间， 不包含SOA2.0代码，超出了 SOA2.0 的控制范围。）
可能的原因：
服务端请求排队， 如果服务端队列中请求较多，那么请求就会等待较长的时间才能被处理
服务端线程池扩容缩容， IIS 服务器会动态调整工作线程池的大小，但是如果频繁的扩容缩容，会影响性能 （可以把最小工作线程池数设置的大一些，以减少扩容缩容的频率，请参考下面的文档）
程序 GC
网络问题

请求在服务端执行完成之后，返回到客户端的耗时很长
可能的原因：
服务端线程池扩容缩容， IIS 服务器会动态调整工作线程池的大小，但是如果频繁的扩容缩容，会影响性能 （可以把最小工作线程池数设置的大一些，以减少扩容缩容的频率，请参考下面的文档）
程序 GC
网络问题
参考文档：
配置 processModel 元素：https://msdn.microsoft.com/zh-cn/library/7w2sway1.aspx
Improving ASP.NET Performance： https://msdn.microsoft.com/zh-cn/library/ff647787.aspx

长尾问题