The following techniques and best practices can be used to improve ASP.NET application performance when it uses ScaleOut StateServer (SOSS) as an ASP.NET Session provider:
1. Minimize network usage and serialization overhead by reducing session size.
All objects in a user’s session state are retrieved at the beginning of each request and updated at the end of each request, regardless of whether the object is used or not. It’s critical to keep that session state collection as small as possible. If you don’t need object data stored in the session dictionary, then consider removing it.
When storing custom data types in session state and these objects are large, consider implementing ISerializable on these classes rather than simply marking them with the [Serializable] attribute. The ISerializable interface allows you to take fine-grained control over serialization and will allow you to decide which members need to be persisted to session state between requests.
Instead of keeping all objects in session state, consider using ScaleOut's NamedCache API (or the newer ScaleOut.Client library) to store portions of session data as separate objects which are just accessed and updated when needed. By storing only the keys to these objects within session state, you minimize the size of session state and avoid transferring data across the network unnecessarily. This will give you fine-grained control over how and when objects are retrieved from ScaleOut StateServer’s distributed, in-memory store. For example, use ASP.NET session state for small objects (for example, simple user information) and put larger objects (such as collections, datasets, or other objects that are not used by every web page) directly into the SOSS store via the NamedCache API, accessing them only as needed.
2. Make full use of the client cache that’s maintained by our client libraries.
To improve performance, SOSS adds an internal “client cache,” for deserialized session objects within its .NET client libraries. When reading sessions, the client cache reduces access response times by eliminating data motion and deserialization overhead for objects that have been recently accessed but not updated in the ScaleOut StateServer store.
The size of the deserialized cache is determined by the max_client_cache parameter in the soss_params.txt file (located in the ScaleOut StateServer installation directory). By default, the cache can consume up to 100000 KB (100 MB) of memory in the w3wp.exe process. Once this limit has been met, the least recently used items will be purged from the cache to make room for new items. The cache should be configured with a large enough value to hold the most recently accessed session state objects.
Configuring your IP load balancer to use sticky sessions (also called “session affinity”) will minimize churning of the client cache and improve performance since a given user’s web requests will always go to the same web server. Be aware that using session affinity can make the load balancer’s distribution of requests less even across all servers.
3. Set ASPX pages to use "ReadOnly" session state whenever possible.
When using session state in an ASP.NET application, setting the @ Page directive's EnableSessionState attribute to ReadOnly can provide significant performance benefits, regardless of whether you're using ScaleOut StateServer's session state provider or one of ASP.NET's built in providers.
The default value for the EnableSessionState attribute is true, which means that the entire session dictionary is retrieved from the ScaleOut StateServer store at the beginning of every web request and then updated at the end of each request, regardless of whether you changed any values in the session dictionary. If you know that a page will never update session state, set the attribute to ReadOnly to prevent updates from occurring. This will cut the number of round trips to the SOSS store in half and eliminate unnecessary updates.
Reducing unnecessary updates also reduces churning of ScaleOut StateServer's client cache. If session data isn't constantly being updated in ScaleOut StateServer's store, the client cache will not have to replace their copies of objects that were recently accessed but not changed. This will increase cache hit rates and improve performance.