views:

230

answers:

1

I am trying to improve the performance of a Silverlight 4 WCF RIA application. As it's for intranet use only, I figured switching from the default binary HTTP binding to the Net.TCP binding might improve performance a bit.

However, I am having a hard time just getting a simple proof of concept application running. I have:

  • switched the proof of conecpt app from Cassini to IIS (7)
  • added the appropriate bindings and enabled protocols on IIS
  • added a clientaccesspolicy.xml file to my IIS root

Now, when I create a context like so:

var context = new DomainService1(
new Uri(
    "net.tcp://localhost:4502/BusinessApplication/BusinessApplication2.Web/ClientBin/BusinessApplication2-Web-DomainService1.svc"));

... I get the following error:

The provided URI scheme 'net.tcp' is invalid; expected 'http'. Parameter name: via

Now I'm stumped. As far as I can tell, the problem is that the client being created by the auto-generated WCF RIA code needs to be told that it's to use a Net.TCP endpoint, but I'm unsure how to do that.

I've found plenty of blog posts explaining how to get WCF services going over Net.TCP, but I haven't found a single one talking about WCF RIA, and I can't find any offical documentation either. All of those explanations involve changes to the web.config file that seem unsuited to a WCF RIA app.

Could some one please either explain to me how to get this configured, or point me at some documentation?

A: 

WCF RIA Services depends on HttpContext which is not available with Net.TCP binding.

As for perf issues, could you elaborate a bit further? What is the bottleneck query/operation? What is the size of data (entity size x entity count)? What is the delta between your perf requirements and current perf?

Perhaps there are other ways that don't involve Net.TCP?

Thanks.

Dinesh

(WCF RIA Services Program Manager)

Dinesh
Dinesh, thanks for the reply. In ~600 characters: we're fetching points for a chart from the server, then calling the server to perform statistical operations multiple times, each time fetching a new set of points. This replaces a VBA legacy app that has to perform near-instantly because of the number of statistical operations requested in real time. 30ms latency has proved acceptable in prototype tests. We're fetching between 30 - 100 entities after each operation, totaling ~12kB according to Fiddler. Current round trip is > 100ms.
Duncan Bayne
Oh and in case you're wondering, we weren't aware of the absolute performance requirements _before_ we started down the WS architecture route. In hindsight, we should have produced prototypes of varying performance _first_ thereby determining some hard numbers for required performance, and incorporating those (as automated performance tests?) from the outset.
Duncan Bayne

related questions