長尾問題

常常有其餘 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