Speed That Scales

Eliminates Bottlenecks to Scaling

Server farms need fast, scalable session-state storage that removes the need for server affinity with in-process storage while keeping session-state off of the database server. ScaleOut SessionServer’s industry-leading in-memory data grid (IMDG) is the answer. Its distributed, memory-based storage provides an out-of-process session-state store that scales with the server farm while keeping mission-critical session-state highly available.

Because session-state is stored in memory, access is fast, and it stays fast since you can scale both its storage capacity and throughput just by adding servers to the grid. Performance tests have demonstrated linear performance scaling and access rates in excess of 1 million reads per second.

Client Caching Makes Access Fast

Built-in client caching dramatically lowers access times over other out-of-process stores (such as a database)  by keeping recently accessed session-state in-process, deserialized, and immediately available to the application. This also reduces network transfer time and CPU deserialization overhead, both of which can become substantial for high workloads. Tests with 10KB session-state objects have demonstrated a 6X reduction in access latency compared to database access.

Sample Reduction in Access Latency by ScaleOut SessionServer

The size of ScaleOut SessionServer’s client cache is configurable to match the needs of the application. Client caches are always kept fully coherent with the state of the IMDG, ensuring that multiple web hits always see a consistent view of session data.

Highly Available

Never Lose Session Data

High availability is critical to enterprise web sites. ScaleOut SessionServer makes sure that that sessions are never lost — even if a server in the data grid fails — by transparently replicating session-state on up to two additional servers within the in-memory data grid (IMDG). If a grid server goes offline for any reason, ScaleOut SessionServer automatically retrieves session objects from other servers in the grid and creates new replicas as necessary to maintain redundant storage.

ScaleOut SessionServer’s peer-to-peer architecture avoids bottlenecks and eliminates any single point of failure. Patented technology ensures that the latest updates are always served to applications if a failure occurs. Deployed at more than 400 sites, ScaleOut SessionServer has been battle-tested for more than a decade on leading e-commerce web sites.

Avoid Site-Wide Failures

You can extend ScaleOut Session Server’s high availability beyond the data center using ScaleOut GeoServer DR to protect against site-wide outages. This product transparently replicates session-state updates to a remote site so that if a data center goes down, a global load-balancer can redirect client requests to the remote site. Both sites can share the workload in a “live-live” configuration with bi-directional replication, and up to eight sites are supported.

Easy to Use and Extensible

Simple to Deploy and Manage

Ease of use is a top priority for ScaleOut Software, and ScaleOut SessionServer was designed to be as easy to manage as possible. It takes only a few minutes to install on each server within a farm, and all servers automatically form a common membership and transparently distribute the workload. You also can deploy ScaleOut SessionServer in public clouds, including Amazon EC2 and Microsoft Azure, using the step-by-step deployment wizard within ScaleOut SessionServer’s GUI management console.

Because of its symmetric, peer-to-peer design, ScaleOut SessionServer has no configuration store to create, manage, or potentially fail. The centralized GUI management console lets system administrators easily manage grid servers, track key performance parameters, and identify issues. A command-line control program also enables scripting of management procedures. ScaleOut SessionServer logs significant events to the Windows Event Log and  includes a comprehensive set of Windows Performance Monitor counters.

Screenshot of the WIndows Management Console

To handle varying workloads, ScaleOut Session Server’s “elastic” in-memory data grid makes it easy to add more servers as the workload increases and then remove them  to conserve resources when not needed. This is especially useful in public clouds where servers can be added on demand.

Flexible Deployment Models

ScaleOut SessionServer can be deployed directly on each web server in the server farm to form a distributed in-memory data grid (IMDG) spanning the farm. There’s no need to configure the IP load-balancer for server affinity since all sessions are accessible from any web server. Also, restarting ASP.NET’s worker process doesn’t affect client sessions because they are safely stored out-of-process in the IMDG.

ScaleOut SessionServer Hosted on a Web Server Farm

ScaleOut SessionServer also can be installed on a separate cluster of grid servers using the Remote Client Option. The use of a dedicated cluster hosting the IMDG is the preferred configuration because it offloads CPU, memory, and networking usage from the web servers, and it allows the IMDG cluster to be provisioned for best performance.  It also allows the IMDG to be managed independently of the web server farm; restarting web servers does not affect the IMDG.

ScaleOut SessionServer Hosted on a Dedicated Server Farm

Extensible for Maximum Performance

Because session-state objects easily can grow to 100s of kilobytes or even megabytes in some applications, care has to be taken to avoid overloading the local area network (LAN), especially when accessing read/write pages on large web sites. This is an inherent consideration for any out-of-process session-state store.

However, ScaleOut SessionServer’s capabilities can be extended using ScaleOut StateServer’s APIs (licensed separately) to overcome this limitation and dramatically boost performance when handling web requests. Instead of holding each client’s complete session-state within a single object, the web application can store portions of the object within the IMDG as separate objects accessed by keys held within the session-state object. This reduces the size of the session-state object and speeds up access during web requests. It also reduces network and CPU overhead, enabling the web site to scale without overloading the LAN.