Last updated: Nov 14 2018

Area: Episerver DXC Service Applies to versions: Not applicable

Session state

This topic explains how to manage session states when using Episerver Digital Experience Cloud Service. Page load time is important, since it correlates with increased conversion rates and better search ranking. Disabling session state can reduce average page load time by enabling parallel processing of requests.

How it works

A session is defined as the period of time that a unique user interacts with the web application. Session state queues up requests from a visitor, so that the information is synched between each request for example when running a website in multiple tabs.

By default, Episerver relies on ASP.NET for managing session states. This default in-memory session state provider enables you to store and retrieve values for a user navigating ASP.NET pages in a web application. In addition, sticky sessions are often used with application load balancing, and means that a visitor is always directed to the same instance in Azure. The combination of these provide a rather performant way of using sessions for non-critical data.

Session state and Episerver features

Core parts of Episerver do not use session state, but the specific functionality listed below does.

  • Self-Optimizing Block
  • Google Analytics - will fallback to request state if session state is disabled.
  • Find tracking - can use current session ID, but will fallback to current user identity name.
  • Forms:
    • Forms use cookies to identify visitors, and DDS as persistent storage. When DDS cannot be written to, Forms use a session state-based storage (IVolatileStorage), for example in form steps. 
    • Captcha validator uses session state, but ReCaptchaValidator can be used instead.

Note: The session requirement for Visitor Groups was removed in Episerver CMS 11.9.0. With this release you can use all visitor groups without session state on the server side. See Session state handling in visitor group criteria.


If an instance is decommissioned because the environment is scaling down, or during code deployment and upgrade of instances, you loose that session state for users on that instance. In most cases this is acceptable for non-critical data. For visitor groups using session state, this means a criterion will not get any matches as the data is no longer available. The matching will have to start from scratch, which in most cases visitors will not notice.

Session state may have a negative impact on performance, deployment and scalability. Therefore, in a load balanced environment of scale, the recommendation is often to disable session state on controllers, or only use it where needed. If you are using session state for storing critical data, consider using another session state provider than the default.


The overall recommendation is to disable session state with DXC Service. Refer to the approaches below, should you decide to use sessions for your solution.

Session state for sites that load data asynchronously

If sessions are enabled, only one request at a time is allowed to be processed by the web server, to ensure there are no concurrency problems when accessing the session store.

The same page loading with sessions disabled:

The importance depends on the nature of your application. It will impact the edit UI, which is heavily asynchronous, and much more responsive without sessions. If the site uses SSL, the difference is even greater, due to modern protocols like SPDY/HTTP2.

Expect sessions to be "lossy"

When using the standard in-proc session provider, session data is only stored in-memory on a single server. The DXC service ensures that visitors are automatically directed to the server holding their session, but as the service infrastructure is continuously scaled to match the load, sessions may be lost.

The cause of loss can be for example:

  • The particular server is unexpectedly shut down.
  • The service automatically provisions a new server.
  • The service scales down capacity.

Sessions can still be a useful caching mechanism for example to hold customer profile information, but the client should be able to automatically recover data from the primary source if a session is destroyed. If you decide to use this option, be sure to monitor how many sessions are lost over time, and adjust your strategy based on that data.

If you require "lossless" sessions

  • Consider storing transactional data in a transactional datastore, for example DDS or SQL.
  • Use the SQL-based session provider.

The SQL-based session provider ensures everything in a session is persisted and can be recovered, even in the case of a disaster affecting the primary region. This insurance comes at a cost, as additional roundtrips to SQL server further increases latency of requests.

Configuring SQL session state

Add the following in Web.config to activate session state for SQL Server:

<sessionState mode="Custom" customProvider="DefaultSessionProvider">
    <add name="DefaultSessionProvider" type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="EPiServerDB" />

Note: Enabling session state for SQL Server may have negative impact on performance for your solution.

Related topics


Do you have feedback on this documentation? Send an email to documentation@episerver.com. For development-related questions and discussions, refer to our Forums on https://world.episerver.com/forum/