Performance
Fast Response Time and Scalability
Relational database servers (DBMS's) have proven their value as the repository for essential line of business data, such as inventory, purchase orders, and billing records. However, mission-critical applications, running on server farms and compute grids often use a DBMS to hold mission-critical but relatively short lived data, such as Web session state, e-commerce shopping carts, and cached application data. This creates significant additional traffic to the DBMS (with a much larger proportion of writes for which the DBMS was not optimized), and it delays responses to client applications.
To eliminate this performance bottleneck, ScaleOut StateServer® (SOSS) provides a distributed, memory-based cache that is hosted directly on a server farm or compute grid, or on a cluster of dedicated caching servers networked to a farm or grid running client applications. SOSS's fast, in-memory storage dramatically reduces response times for repeatedly accessing cached data in comparison to database access, and its access throughput linearly scales as servers are added to the farm. These performance characteristics enable SOSS to maintain very fast and predictable response times even under very high access loads, while simultaneously offloading the database server.
Fast Response Time
ScaleOut StateServer incorporates several internal mechanisms that automatically accelerate access requests and minimize response times. ScaleOut StateServer can deliver read access times that are very close to the performance of an "in process" store and significantly better than access times for other "out of process" stores. For example, the chart below shows SOSS's average read access time (in msec.) for multiple reads to a Web session-object with a 100KB dataset. This chart shows that SOSS reduces the average read access time six-fold in comparison to the use of either a standalone, networked, in-memory session-state server or a database server.

To help achieve these fast response times, SOSS transparently employs multiple, internal caches that automatically accelerate accesses to cached objects. These internal caches include:
- API cache: a cache of references to recently accessed, deserialized data objects, which is maintained by the SOSS API client libraries in each application process, and a
- server cache: a cache of recently accessed, serialized objects maintained by the SOSS service on each server in the farm or grid.
These caches are tightly integrated and kept coherent with SOSS's highly optimized, distributed, in-memory storage to ensure much lower access times than other storage alternatives while maintaining global accessibility across the farm to all stored data.
Scalable Throughput
In addition to providing very fast response times, ScaleOut StateServer automatically scales its throughput to handle additional client load as servers are added to the server farm or compute grid. This keeps response times from growing due to access bottlenecks under even the most demanding loads. In contrast, storage solutions with fixed throughput, such as database servers, experience rapidly increasing response times as their maximum throughput is reached.
To illustrate the advantages of ScaleOut StateServer's scalable throughput, two scalability tests were performed. In the first test, the access throughput of SOSS's distributed cache was compared to the throughput of a relational database server as access load was proportionally scaled by adding application servers to the server farm. Each application server sequentially performed continuous read/update access requests to 20,000 1K byte objects. Note that in the case of a Web server farm, the objects could represent concurrent users accessing the server farm and maintaining Web sessions (one per object). The average time to complete a read and update was recorded while servers were added to the farm until 28 servers with a total of 560K objects were in use. For comparison purposes, response times also were measured for the same read/update operations on a database server in which the objects likewise were stored.
The chart below shows that SOSS's average response time (shown as the blue bars) remained flat as objects and hosts were added to the farm. This demonstrates the benefit of the distributed cache's scalable throughput, which increased linearly as the server farm grew from 3 to 28 hosts. In contrast, the database server exhibited a non-linear increase in response times (the red bars) as the object count and access load increased. The database server was almost 20X slower than SOSS's distributed cache under the maximum load of 28 servers and 560K objects.

The second test confirmed SOSS's linear scalability under very high load on a large computational grid. Read/update access tests with 10KB objects and 4K objects per server were run on a high performance grid using H-P four-way multiprocessor blades and a 20Gbits/second Infiniband network; this grid was incrementally increased from 4 servers to 64 servers. As servers were added to the grid, the load was proportionately increased, and the aggregate access throughput was measured. The total data size stored in the distributed cache on 64 servers reached approximately 2.5GB. Note that SOSS's automatic data partioning and dynamic load balancing mechanisms allows servers to be added to the grid without the need for any cache configuration changes by the user.
As illustrated in the graph below, this test demonstrated that SOSS's access throughput grows linearly as servers and access load are increased. This shows that the distributed cache delivers maximum scalability in both its throughput and storage capacity, which enables applications to enjoy the fastest possible access times for very large, access-intensive computations.

Summary
ScaleOut StateServer's combination of fast response time and scalable throughput delivers the industry's highest performance distributed caching for server farms. SOSS makes it easy for application developers to tap its full performance by incorporating advanced capabilities that automatically manage the distributed cache and always keep cached data where it's needed. Now developers finally have a powerful solution for offloading database servers and accelerating application performance and scalability.
|