Session state

Page load time is important because it correlates with increased conversion rates and better search ranking. Turning off the session state can reduce average page load time by enabling parallel processing of requests.

A session is defined as the period 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, such as when you run a website in multiple tabs.

By default, Optimizely relies on ASP.NET Core for managing sessions. This in-memory session state provider lets you store and retrieve values for a user navigating ASP.NET pages in a web application. Also, sticky sessions are often used with application load-balancing so that a visitor is directed to the same instance in Azure. Combining these provides a performant way of using sessions for non-critical data.

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

• Google Analytics – Will fall back to request state if session state is disabled.
• Find tracking – Can use current session ID, but will fall back 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 you can use ReCaptchaValidator instead.

Considerations

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

Session state may hurt performance, deployment, and scalability. In a load-balanced scale environment, you should turn off the controller's session state 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.

Recommendations

You should turn off the session state with DXP. See the following approaches if you decide to use sessions for your solution.

Session state for sites that load data asynchronously

If sessions are turned on, the web server can only process one request at a time 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 more responsive without sessions. The difference is even greater if the site uses SSL 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 DXP 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:

• 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 to hold customer profile information. Still, 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, 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 <g class="gr_ gr_91 gr-alert gr_gramm gr_inline_cards gr_run_anim Punctuation only-ins replaceWithoutSep" id="91" data-gr-id="91">example</g> DDS or SQL.
• Use the SQL-based session provider.

The SQL-based session provider ensures everything in a session persists 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 the SQL server further increase requests' latency.

Configure SQL session state

Add the following in Startup.cs to activate session state for SQL Server:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env) {
  if (env IsDevelopment()) {
    app.UseDeveloperExceptionPage();
  }

  app.UseStaticFiles();
  app.UseRouting();
  app.UseAuthentication();
  app.UseAuthorization;
  app.UseSession();
  app.UseEndpoints(endpoints => {
    endpoints.MapContent();
    endpoints.MapControllerRoute(
      name: "default",
      pattern: "{controller=Home}/{action=Index}/{id?}");
    endpoints.MapRazorPages();
  });
}

🚧

Caution

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