WCF：显着滞后通过HttpBinding返回大数据集吗？

Question

I have a WCF service using Entity Framework 6 hosted in a simple Windows Forms app. My WPF client app requests a large view (11000 records) from the service which is added to an ObservableCOllection. The client machine is connected to our VPN over WiFi.

When I run SQL Server Profiler on the db I can see that the query itself is very fast however, the Audit Logout duration is long, suggesting that the connection is staying open for a long time as WCF returns the data to the client over Http:

When on my networked Dev machine, this transaction is very fast. If I reduce the query results (eg SELECT TOP 200...) the process speeds up considerably therefore I know it is the sheer volume of data causing the issue.

Here is my current binding:

 <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>

I have tried implemented Mtom messaging but this had no noticeable positive effect. I have read around using GZip compression with a custom binding. Is this the best course of action? the implementation documentation is very thin.

Failing that, is it likely that Net TCP binding could prove more efficient and if so how is this implemented when hosting a WCF service in a Winforms app rather than with IIS?

Unfortunately, the user requirements dictate that the whole view is returned to the client UI, I cannot page or async the results.

Answer 1

I have serious concerns over the statement

I have a WCF service using Entity Framework 6 hosted in a simple Windows Forms app

This paints a very confused picture to me. It suggests that you have a "master" WPF app with the service in it, and then you distribute a bunch of WPF client apps which have the WCF client in them? The config sample you have provided defines a service client, not a service host. There are many reasons why a WPF app is a very unsuitable host for a wcf service.

The user edits articles from all over the world. The articles are defined by country. Therefore I can't serve up say TOP 200 as then the user will only receive 'Afghanistan' articles. They need to be able to scroll to their country of interest

This is the key to addressing your problem. The data can be effectively sharded (or even exposed using views) into smaller sets of data, maybe by country and date as an example.

Failing that, is it likely that Net TCP binding could prove more efficient and if so how is this implemented when hosting a WCF service in a Winforms app rather than with IIS?

Yes! netTcpBinding is much faster than http. That would certainly speed stuff up. You can use it over the internet but be aware that firewalls block TCP traffic on unopenned ports.

The wcf hosting container being WPF doesn't limit you to choice of transport bindings, but remains a very unorthodox choice.

Answer 2

When I run SQL Server Profiler on the db I can see that the query itself is very fast

You have you used a SQL profiler, but you haven't provided any profiling information related to your WCF service, EF etc. which is much more important for troubleshooting this.

Assuming your message size is 4KB, that would mean you are transferring dozens of MB over the wire at once, and in addition using buffering on both ends, which is not optimal for big payloads. Default XML Serialization/Deserialization of those records is a problem too, because its slow. Pulling 11K using an ORM like EF is also not a good idea, because its slower than ADO.NET or MicroORMs. So your whole architecture is wrong.

I've tried to stream the response, didn't make any difference.

Streaming is more efficient for big messages than Buffering, but it must be implemented correctly on the server, and especially on the client to have an effect. If you use streams the wrong way, they could be slower than buffering.

However, optimizing the current implementation is not the right approach, your actual problem is the assumption you need 11K records upfront on the UI. You should re-think your UI architecture and pull data on demand.

Unfortunately, the user requirements dictate that the whole view is returned to the client UI, I cannot page or async the results.

One of the techniques you could use is infinite scrolling . There are many more.

In addition, you should use Async IO whenever you are dealing with remote services, unless you want to kill the scalability of your app.