View source for Remoting (.NET 1.1) Performance Guidelines - Activation

From Guidance Share

← Remoting (.NET 1.1) Performance Guidelines - Activation

You do not have permission to edit this page, for the following reason:

---

You can view and copy the source of this page.

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, and Alex Mackman == Use CAOs only where you need to control the lifetime. == The lifetime of the CAOs can be controlled by the calling application domain, just as if they are local to the client. Each time a client creates an instance of a client-activated type, that instance services only that particular reference in that particular client until its lease expires and its memory is recycled. If a calling application domain creates two new instances of the remote type, each of the client references invokes only the particular instance in the server application domain from which the reference was returned. For more information, see "Lifetime Considerations." == Consider the limited scalability offered by CAOs. == CAOs are not generally recommended, due to scalability limitations. Objects activated at the client cause the client proxy reference to be bound to a specific server where the server object was activated. This server affinity reduces the ability of your application to scale, and it negatively impacts performance because load on the individual server increases. When the server load increases, there is no way to offload the calls from the client to another server in the farm that has less load. If you have a single server solution, this is not an issue. However, if you need to scale out and use a server cluster, CAOs significantly limit scalability. CAOs do provide the benefit of allowing the server object to maintain state across method calls. Generally, it is better to design stateless objects for performance and scalability. Note Any Marshal by Reference Objects (MBROs) returned by the remote object will be treated like CAOs and will suffer this issue as well. Therefore, it is not recommended to return MBRO objects from remoting calls. == Use singleton where you need to access a synchronized resource. == Singleton is the preferred solution if you need to have a synchronized access to any resource; for example, a read/write operation being performed on a file. Using singletons ensures that there is only a single instance serving the requests from the clients. == Use singleton where you need to control lifetime of server objects. == Singletons are subject to lifetime leases that are specified for the objects. However, they can be recycled even if clients hold references to the objects after the lease time expires. Therefore, if you need to control the lifetime of server-activated objects, use singletons. == Use appropriate state management to scale the solution. == The difference between the CAOs and singletons is that of affinity. Singletons can be scaled if they are stateless. Singletons can be used for serving calls from multiple clients, whereas CAOs can be used only for serving calls from the same client for a particular reference. The CLR provides a thread pool to service incoming client calls. As a result, singleton SAOs that maintain shared state require synchronization code to ensure valid state management. == Use SingleCall SAOs for high scalability. == Single call objects live only for the life of the method call. They cannot maintain state, because they are destroyed after servicing the method. Single call objects are free from synchronization code, because they serve only requests for a single client before being destroyed. Using single call objects, combined with the HttpChannel and IIS as the host, gives maximum scalability for a .NET remoting solution. [[Category: Remoting (.NET 1.1)]] [[Category: Guidelines]]

Return to Remoting (.NET 1.1) Performance Guidelines - Activation.