Geek Answers Handbook

PerSession vs PerCall

Which general rule determines whether to use PerSession or PerCall?

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

I divided the WCF service into 7 contracts within 1 service (i.e. 7 endpoints within 1 service), so that each contract takes care of its own domain, for example, I have a sales contract, therefore all the tables related to sales, and its related operations are within the limited context of sales

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 for PerCall is that since I have a fairly large DB / WCF service, I am afraid that the amount of resources consumed by each call is multiplied by the number of users and the speed with which they call the service would be too high.

I don’t know the small details, but I read that creating proxy channels is an expensive operation.

Oh, I use hand-encoded proxies instead of VS. Add a service link to use my WCF service.

So my question is what should I use? PerSession or PerCall?

Update:

  • I do not need to maintain state between calls.
  • I use NetTCP bindings
+4
source share
2 answers

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

  • To migrate from InstanceContextMode.PerSession - If your users have some session values ​​stored in the WCF service on the server.
  • To switch from InstanceContextMode.PerCall - if your users do not store anything in a session in the WCF service on the server, for example, the WCF service does not require any user settings necessary for storing in memory. Scalability required.

Some points regarding When-And-Why,

InstanceContextMode.PerCall

  • If your service is stateless and scalable, then the benefits are similar to HTTP, as they are stateless as well.
  • If the service has a light initialization code (or nothing at all).
  • If your service is single threaded.
  • Example scenario:. For any 1000 client requests over a certain period of time, only 100 objects will be created in PerCall for 100 active calls. Secondly, if the server crashed, then in the PerCall situation PerCall only errors that will occur will be associated with the 100 actual requests that were executed (provided that they quickly switched to another resource). Another 900 clients can be redirected to another server on the next call.

InstanceContextMode.PerSession

  • If your service needs to maintain some state between calls from the same client.
  • If your service has a light initialization code (or nothing at all). Although you only get a new instance for each client proxy, you still want to be careful about the expensive initialization code in the constructor.
  • Example scenario: For any 1000 client requests for a certain period of time in PerSession situation can have 1000 objects created on the server, but only 100 are actually active > when called at any time. And thus, created PerSession objects can be a waste of resources and can affect the ability to serve requests under load. Secondly, if the server crashes, and then in PerSession , all 1000 clients that have a session on this server will lose the session and will not be able to shut down.

Link References:

+15
source

The reason you do not see many answers to this question online is because it depends. I would try to do this - then open perfmon on the server where you host the service and add counters for your service. Just google wcf performance manager pointers if you are not familiar.

The good news is that WCF changes settings very easily.

If you are interested in the cost of creating a proxy server on the client side, remember that perCall is the behavior of the service, not the behavior of the client. Even if you set the context of the service instance in PerCall, you can still create one instance of your proxy and make a bunch of method calls from this proxy. All perCall means that when you make a call, a service instance is created, a method is called, and the service instance is broken again. Unless you have a costly initialization of a service instance (i.e. if they are mostly static methods), you probably agree with every call.

+1
source

More articles:


All Articles