WCF Internals  
Author Message
Avner Kashtan





PostPosted: Windows Communication Foundation ("Indigo"), WCF Internals Top

Is there any whitepaper out there that details some of the internal behavior of the WCF listener framework

I would like to know things like the implications of running several services in the same process as opposed to splitting them into different processes running in parallel. I want to know if having all my services listening on the same TCP port (netTcpBinding) has any performance implications as opposed to having each service listen on a different port.

I know that ASP.NET had several good whitepapers on the HTTP Pipeline and some "what happens when" timelines that detail what the runtime does when a request is received. Is a similar document planned for WCF



Visual Studio 200820  
 
 
Madhu Ponduru -MSFT





PostPosted: Windows Communication Foundation ("Indigo"), WCF Internals Top

Hi Avner,

I think this is valid request,we are in the process of writing white papares on interop,integration and performance,I will make sure we have bug to track this request.

question #1 :

I would like to know things like the implications of running several services in the same process as opposed to splitting them into different processes running in parallel.

[Answer]

This is same as ASP.NET model,as you know,every windows process will get limited resources for process,so if your application required too much memory or other windows resourcse,it may impact other App domains in same process(assuming we have more resources at machine level),that time,going to new app pool may add more performance.

question #2:

I want to know if having all my services listening on the same TCP port (netTcpBinding) has any performance implications as opposed to having each service listen on a different port

[Answer]

I am assuming we will receive calls synchrously,If you are getting too many requests too fast, port sharing mode may have some impact on performance (I will cross check with my dev team and I will try to give you definite answer for this question)

[From TcpListener doc]

The TcpListener class provides simple methods that listen for and accept incoming connection requests in blocking synchronous mode

 



 
 
Kenny Wolf





PostPosted: Windows Communication Foundation ("Indigo"), WCF Internals Top

By default we receive asynchronously on our IO sockets. You can override this default by adding System.ServiceModel.Description.SynchronousReceiveBehavior to your Endpoint Behaviors on your Service.

In general, the downside to multiple port#s is surface area (needing to open up firewall ports, etc) and resource consumption (extra handles). In general you won't see any performance difference. One reason to use different port #s was if you wanted completely different configurations (one with high scalability settings and one with tighter throttling settings for example).



 
 
Avner Kashtan





PostPosted: Windows Communication Foundation ("Indigo"), WCF Internals Top

Ok, so now you have me confused. :)

I have several services listening on net.tcp, currently using different ports. I would like to consolidate them to a single port to simplify deployment and decrease the attack surface, and wanted to make sure that I won't experience any performance penalties.

As Madhu says, the basic TcpListener class implements a blocking, synchronous listener. I assume the WCF classes that wrap it implement the asynchronous behavior and call my service methods without blocking each-other.

Assuming that I don't have any of the networking scenarios you described (different throttling behaviors for different services, for instance) - is there any reason NOT to host them all on the same port

EDIT: Just to give a bit more info on the scenario - we're talking about 5-10 services (depending on scale-out) of which one is a high traffic hub with possibly dozens or hundreds of calls per second. The rest are much lower frequency (every several minutes on average load).


 
 
Kenny Wolf





PostPosted: Windows Communication Foundation ("Indigo"), WCF Internals Top

Sorry for the confusion.

Our TCP Transport is built on top of Socket directly, not on top of TcpListener, and yes by default we will be asynchronous with our receives. If you are already hosting your services in the same app-domain, you might as well host them all at the same port# as well.

If for some reason you need extra isolation (i.e. don't want one service to take down the others if there's an errant bug), then you would separate your services into separate exes. In that case you can only use the same port through SMSvcHost.exe, our out-of-proc TCP port-sharing exe.

Hope this helps.



 
 
Avner Kashtan





PostPosted: Windows Communication Foundation ("Indigo"), WCF Internals Top

If you are already hosting your services in the same app-domain, you might as well host them all at the same port# as well.

Thanks for the information, this is exactly what I wanted to know.

Regarding the point above, though - is there a way to instruct the ServiceHost to instantiate my services in a seperate AppDomain

Not a seperate AppDomain per instance, since that will probably be much too wasteful, but have either ServiceHost have its own AppDomain in which it creates all service instances

That way the ServiceHosts themselves sit in the same process and share resources (such as the TCP port), but my code itself runs isolated in its own AppDomain.


 
 
Adiavn





PostPosted: Windows Communication Foundation ("Indigo"), WCF Internals Top

Why not just create the servicehost in a new appdomain
 
 
Avner Kashtan





PostPosted: Windows Communication Foundation ("Indigo"), WCF Internals Top

Why not just create the servicehost in a new appdomain

Because I want to be sure that any resources that CAN be shared between ServiceHosts - such as TCP ports - ARE shared. If I open my ServiceHosts in different appdomains, can they still share ports or do they have to go through the Port Sharing Service just like they were different processes