WCF服務 - 呼叫重定向問題

我們有一個託管在IIS上的WCF服務。該服務接收請求並基於其中一個請求參數，它自己提供請求或將其重定向到其他服務器。重定向的過程實質上是對另一個經典Web服務（asmx）的調用。WCF服務 - 呼叫重定向問題

我們一直面臨的問題是，當我直接調用asmx服務時，我們得到的響應時間不到20毫秒，但是當通過WCF服務調用響應時，響應時間會縮短到300毫秒。我的推測是，請求在被分派到WCF服務的asmx服務之前正在某處（IIS）被阻止。我一直試圖檢查性能計數器，但是，看不到任何計數器，我可以從中得出任何結論。我也檢查了IIS日誌，這也不是很好的指示。

我試圖ping託管服務器主機asmx服務託管wcf服務的服務器，它只需要幾乎3ms獲得響應回來。

有沒有什麼辦法可以讓我得出結論：通話中多餘的時間在何處？

更新 - 我試着使用Fiddler，它將響應時間縮短到20 ms apprx。如果我刪除提琴手，響應時間上升到200毫秒

從框架3.5調用時建立在Framework 2.0中的服務可能會響應速度慢嗎？

更新2 我們已經縮小到代理的問題。如果我們拒絕fiddler中的代理選項，響應時間會增加。對WCF服務的調用是在basicHttpBinding上進行的，後者又調用asmx服務。它看起來像Fiddler緩存代理並在下次重新使用它。如果這種理解是正確的，那麼在我們的設置中是否可以實現類似的東西？

來源

2014-10-30 vibhu

我將從諸如ANTS Profiler或Visual Studio等工具分析WCF服務開始。此外，這是發生在單個電話還是重負載？ – 2014-10-30 08:47:54

這也適用於單個呼叫。 – vibhu 2014-10-30 09:22:58

事實證明，我們的服務期望將100Continue設置爲false。我們使用Wireshark檢查了網絡傳輸，發現當請求結束時沒有附加expect100Continue時，服務器託管asmx服務的響應延遲。更多關於期望100繼續這裏 - expect100Continue

來源

2014-11-04 10:24:46 vibhu

我們的應用程序需要接近實時性能。在進一步討論之後，我們決定將useNagelAlgorithm設置爲false。保持expect100繼續可能會導致負載平衡環境中的問題。 – vibhu 2014-11-06 03:24:37

WCF服務 - 呼叫重定向問題

回答

相關問題