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。