WCF：顯着滯后通過HttpBinding返回大數據集嗎？

Question

我有一個使用Entity Framework 6的WCF服務，該服務托管在一個簡單的Windows Forms應用程序中。 我的WPF客戶端應用程序從服務中請求一個大視圖（11000條記錄），該服務已添加到ObservableCOllection。 客戶端計算機通過WiFi連接到我們的VPN。

當我在數據庫上運行SQL Server Profiler時，我可以看到查詢本身非常快，但是， Audit Logout持續時間很長，這表明連接保持打開狀態很長時間，因為WCF通過Http將數據返回給客戶端：

在我的聯網Dev機器上時，此事務非常快。 如果我減少查詢結果（例如SELECT TOP 200 ...），則該過程將大大加快速度，因此，我知道是導致問題的龐大數據量。

這是我當前的綁定：

 <system.serviceModel>
    <bindings>
        <basicHttpBinding>
            <binding name="BasicHttpBinding_IIsesService" maxBufferSize="2147483647"
             maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" useDefaultWebProxy="false" />
        </basicHttpBinding>
    </bindings>
    <client>
        <endpoint address="http://emea-diis01v:8082/" binding="basicHttpBinding"
            bindingConfiguration="BasicHttpBinding_IIsesService" contract="ServiceReference.IIsesService"
            name="BasicHttpBinding_IIsesService" />
    </client>      
</system.serviceModel>

我已經嘗試過實施Mtom消息傳遞，但這沒有明顯的積極作用。 我已經閱讀了將GZip壓縮與自定義綁定結合使用的信息。 這是最好的做法嗎？ 實施文檔非常薄。

如果不這樣做，是否有可能證明Net TCP綁定會更有效？如果是這樣，當在Winforms應用程序中而不是與IIS中托管WCF服務時，如何實現此目的？

不幸的是，用戶需求表明整個視圖都返回到客戶端UI，我無法分頁或異步處理結果。

Answer 1

我對此聲明感到嚴重關切

我有一個使用Entity Framework 6的WCF服務，該服務托管在一個簡單的Windows Forms應用程序中

這給我描繪了一幅非常困惑的圖畫。 它建議您有一個帶有服務的“主” WPF應用程序，然后再分發一堆其中裝有WCF客戶端的WPF客戶端應用程序？ 您提供的配置示例定義了服務客戶端，而不是服務主機。 WPF應用程序不適合用作wcf服務的宿主有很多原因。

用戶編輯來自世界各地的文章。 文章按國家/地區定義。 因此，我無法說出前200名，因為用戶只會收到“阿富汗”文章。 他們需要能夠滾動到感興趣的國家

這是解決您的問題的關鍵。 該數據可以是有效地分片 （或甚至使用視圖曝光）成更小的數據集，可能因國家和日期，例如，

如果不這樣做，是否有可能證明Net TCP綁定會更有效？如果是這樣，當在Winforms應用程序中而不是與IIS中托管WCF服務時，如何實現此目的？

是! netTcpBinding比http 快得多 。 那肯定會加快速度。 您可以通過Internet使用它，但請注意防火牆會阻止未打開端口上的TCP通信。

作為WPF的wcf托管容器不會限制您選擇傳輸綁定，但仍然是非常不合常規的選擇。

Answer 2

當我在數據庫上運行SQL Server Profiler時，我可以看到查詢本身非常快

您使用過SQL事件探查器，但未提供任何與WCF服務，EF等有關的分析信息，這對於解決此問題更為重要。

假設您的消息大小為4KB，這意味着您一次要通過網絡傳輸數十MB的數據，此外還要在兩端使用緩沖，這對於大負載而言並不是最佳選擇。 這些記錄的默認XML序列化/反序列化也是一個問題，因為它很慢。 使用像EF這樣的ORM提取11K也不是一個好主意，因為它比ADO.NET或MicroORM慢。 因此，您的整個體系結構是錯誤的。

我嘗試流式傳輸響應，沒有任何區別。

對於大消息，流傳輸比“緩沖”更為有效，但是必須在服務器上（尤其是在客戶端上）正確實現流才能生效。 如果以錯誤的方式使用流，則它們可能比緩沖慢。

但是，優化當前實現不是正確的方法，您的實際問題是假設您需要在UI上預先存儲11K條記錄。 您應該重新考慮UI架構並按需提取數據。

不幸的是，用戶需求表明整個視圖都返回到客戶端UI，我無法分頁或異步處理結果。

您可以使用的一種技術是無限滾動 。 還有更多。

此外，除非要終止應用程序的可伸縮性，否則在處理遠程服務時都應使用Async IO。