PerSession vs. PerCall

Question

What's the general rule of thumb to decide whether to use PerSession or PerCall?

I have a slightly heavy (I think..) WCF service, containing CRUD methods to about 80 tables.

I have separated the WCF service into 7 contracts within 1 service, (i.e., 7 end points within 1 service) such that each contract takes care of its own domain, for example I have a Sales contract, so all sales related tables, and its corresponding operations are within the sales "bounded context"

So my WCF service structure looks something like this:

public partial class ABCService : ISalesService
{
   //CRUD methods of all tables related to Sales
}

public partial class ABCService : IMarketingService
{
    //CRUD methods of all tables related to Marketing
}

public partial class ABCService : ICustomerService
{
    //CRUD methods of all tables related to Customer
}

public partial class ABCService : IProductService
{
    //CRUD methods of all tables related to Products
}

My concern with PerCall is that, because I have a fairly large DB/WCF service, I'm afraid that the amount of resources consumed by each call, multiplied by the number of users and the rate of which they call the service, would be far too great.

I do not know the fine details, but I have read that creating a Channel Proxies are expensive operations.

Oh, I'm using hand coded proxies instead of VS's Add service reference to consume my WCF service.

So, my question is, which should I use? PerSession or PerCall?

Update:

1. I do not need to maintain state between calls.
2. I'm using NetTCP bindings

Answer 1

In my opinion, to take a decision consider these two points

1. For going with InstanceContextMode.PerSession - If your users have some session values stored on the WCF service on the server.
2. For going with InstanceContextMode.PerCall - If your users have nothing stored in session on the WCF service on the server i.e. WCF service requires No per user settings required to store in memory. Requires scalability.

Some points regarding When-And-Why,

InstanceContextMode.PerCall

• If your service is stateless and scalable, i.e. benefits are similar to HTTP as it is also stateless.
• If service has light-weight initialization code (or none at all).
• If your service is single threaded.
• Example scenario: For any 1000 client requests in a given time period in a PerCall situation, there will only be 100 objects instantiated for 100 active calls. Secondly if server were to crash then in PerCall situation the only errors that would occur would be to the 100 actual requests that were in progress (assuming fast failover). The other 900 clients could be routed to another server on their next call.

InstanceContextMode.PerSession

• If your service has to maintain some state between calls from the same client.
• If your service has light-weight initialization code (or none at all). Even though you are only getting a new instance for each client proxy, you still want to be careful about having expensive initialization code in a constructor.
• Example scenario: For any 1000 client requests in a given time period in a PerSession situation you may have 1000 objects instantiated on the server but only 100 are actually active in call at any moment. And thus instantiated PerSession objects could be a waste of resources and may impact the ability to serve requests under load. Secondly if server were to crash then in PerSession all 1000 clients who have a session on that server would lose their session and be unable to complete their work.

Reference links:

1. MSDN - WCF Instancing, Concurrency, and Throttling
2. SO - Per-Call vs Per-Session
3. MSDN - Using Sessions in WCF context

Answer 2

The reason you don't see many answers to this type of question online is that it depends. What I would do is try it out -- then open up perfmon on the server where you are hosting the service and add the counters for your service. Just google wcf performance manager counters if you aren't familiar.

The good news is that WCF makes changing the setup pretty easy.

If you are concerned with the cost of instantiating a proxy on the client side, remember that perCall is a service behavior, not a client behavior. Even if you set the service instance context to PerCall, you can still create one instance of your proxy and make a bunch of method calls from that proxy. All perCall means is that when you make a call, an instance of the service is created, your method is called, and the instance of the service is torn down again. If you don't have any expensive initialization on the service instance (i.e. if they're basically static methods) you're probably ok with per call.