WebSphere eXtreme Scale Administration Guide > Configure WebSphere eXtreme Scale > Cache integration > WebSphere eXtreme Scale dynamic cache provider



Capacity planning and high availability


The Dynamic Cache API is available to Java™ EE applications that are deployed in WebSphere Application Server. The dynamic cache can be leveraged to cache business data, generated HTML, or to synchronize the cached data in the cell by using the data replication service (DRS).


Overview

All dynamic cache instances created with the WebSphere eXtreme Scale dynamic cache provider are highly available by default. The level and memory cost of high availability depends on the topology used.

When using the embedded topology, the cache size is limited to the amount of free memory in a single server process, and each server process stores a full copy of the cache. As long as a single server process continues to run, the cache survives. The cache data will only be lost if all servers that access the cache are shut down.

For caching using the embedded partitioned topology, the cache size is limited to an aggregate of the free space available in all server processes. By default, the eXtreme Scale dynamic cache provider uses 1 replica for every primary shard, so each piece of cached data is stored twice.

Use the following formula A to determine the capacity of an embedded partitioned cache.


Formula A

F * C / (1 + R) = M

Where:

For a WebSphere Network Deployment grid that has 256 MB of available space in each process, with 4 server processes total, a cache instance across all of those servers could store up to 512 megabytes of data. In this mode, the cache can survive one server crashing without losing data. Also, up to two servers could be shut down sequentially without losing any data. So, for the previous example, the formula is as follows:

256mb * 4 containers/ (1 primary + 1 replica) = 512mb.

Caches using the remote topology have similar sizing characteristics as caches using embedded partitioned, but they are limited by the amount of available space in all eXtreme Scale container processes.

In remote topologies, it is possible to increase the number of replicas to provide a higher level of availability at the cost of additional memory overhead. In most dynamic cache applications this should be unnecessary, but you can edit the dynacache-remote-deployment.xml file to increase the number of replicas.

Use the following formulas, B and C, to determine the effect of adding more replicas on the High Availability of the cache.


Formula B

N = Minimum(T -1, R)

Where:


Formula C

Ceiling(T/ (1+N)) = m

Where:

For performance tuning with the dynamic cache provider, see Tune the dynamic cache provider.


Cache sizing

Before an application using the WebSphere eXtreme Scale Dynamic Cache provider can be deployed, the general principals described in the previous section should be combined with the environmental data for the production systems. The first figure to establish is the total number of container processes and the amount of available memory in each process to hold cache data. When using the embedded topology, the cache containers will be co-located inside of the WebSphere Application server processes, so there is one container for each server that is sharing the cache. Determining the memory overhead of the application without caching enabled and the WebSphere Application Server is the best way to figure out how much space is available in the process. This can be done by analyzing verbose garbage collection data. When using the remote topology, this information can be found by looking at the verbose garbage collection output of a newly started standalone container that has not yet been populated with cache data. The last thing to keep in mind when figuring out how much space per process is available for cache data, is to reserve some heap space for garbage collection. The overhead of the container, WebSphere Application Server or stand-alone, plus the size reserved for the cache should not be more than 70% of the total heap.

Once this information is collected, the values can be plugged into formula A, described previously, to determine the maximum size for the partitioned cache. Once the maximum size is known, the next step is to determine the total number of cache entries that can be supported, which requires determining the average size per cache entry. The simple way of doing this is to add 10% to the size of the customer object. See theTune guide for dynamic cache and data replication service for more in depth information on sizing cache entries when using Dynamic Cache.

When compression is enabled it affects the size of the customer object, not the overhead of the caching system. Use the following formula to determine the size of a cached object when using compression:

S = O * C + O * 0.10

Where:

So, a 2 to 1 compression ratio is 1/2 = 0.50. Smaller is better for this value. If the object being stored is a normal POJO mostly full of primitive types, then assume a compression ratio of 0.60 to 0.70. If the object cached is a Servlet, JSP, or WebServices object, the optimal method for determining the compression ratio is to compress a representative sample with a ZIP compression utility. If this is not possible, then a compression ratio of 0.2 to 0.35 is common for this type of data.

Next, use this information to determine the total number of cache entries that can be supported. Use the following D formula:


Formula D

T = S / A

Where:

Finally, set the cache size on the dynamic cache instance to enforce this limit. The WebSphere eXtreme Scale dynamic cache provider differs from the default dynamic cache provider in this regard. Use the following formula to determine the value to set for the cache size on the dynamic cache instance. Use the following E formula:


Formula E

Cs = Ts / Np

Where:

Set the size of the dynamic cache instance to a value calculated by formula E on each server that shares the cache instance.



Parent topic

WebSphere eXtreme Scale dynamic cache provider


+

Search Tips   |   Advanced Search