Previous | Home
6.5 Sizing guidance
Overview
If you already use the default dynamic cache provider, then you probably know how much data you cache today, and therefore how much you plan to cache with eXtreme Scale. You will currently have the environment set to either...
- maximum number of cache entries
- maximum cache size
The Cache Monitor application can show you how well utilized the cache is, and give an indication of how many objects it is desirable to cache.
Use the following metrics to determin how to size an eXtreme Scale grid....
How many cache entries to store?
In our example, we use 100,000 entries.
What is the average size of a data entry is going to be in eXtreme Scale?
Estimate the size using the Extended Cache Monitor MBean statistics.
In eXtreme Scale, this data will be compressed. For web content, estimate a compression ratio of 0.4, which is the worse compression than you're likely to see.
Avg object size= MemoryCacheSizeInMB * Compression Ratio / MemoryCacheEntriesIn our example, the average cached object size is 25kb.
If you do not yet have these metrics for the Commerce site, take a typical page and compress it using an archive tool to give an indicative size.
How resilient do you want the cache?
In eXtreme Scale terms this is how many replicas you want. The default of one asynchronous replica will likely be sufficient.
How much space do you have in a WebSphere eXtreme Scale container or JVM?
Do not exceed 70% of the application server heap to allow room for garbage collection. Also, leave room for JVM and WebSphere services to run. You can verify how much space would be available by looking at how much memory an empty WebSphere Application Server takes up. In our test, it was around 50Mb.
For our example, we will assume that out of a maximum heap of 1.5 Gb, we have 1 Gb for caching data.
Having collated or estimated the prerequisite data, size the grid as follows:
- Calculate the total size of the cached data.
Total cache size = Avg object size * Num entries to cache * (1 + Num replicas)For our example, the total cached data would be:
25kb * 100000 * (1 + 1) = 5000000kb or 5Gb
- Calculate how many eXtreme Scale containers are needed to host the data.
Num eXtreme Scale containers = Total cache size / Free memory per container
For our example, the number of containers would be:
5 / 1 = 5 containers
Consider the availability requirements in deciding the number of eXtreme Scale containers. If the number of containers comes out quite low, then determine the number of containers based on what minimum is required to have an available configuration. For example, three or four containers spread over two servers is the recommended minimum to ensure an even spread of data partitions in the grid.
- Work out the cache size setting.
Remember that the cache size setting on the application server dynamic cache service relates to separate things depending on whether you are using eXtreme Scale as the dynamic cache provider. By default, the cache size setting refers to the size of the whole cache. With eXtreme Scale, the cache size setting refers to the number of cache entries per partition.
Cache size setting = Num entries to cache / Num partitions
For our example, the cache size setting would be:
100000 / 47 = 2128 cache entries per partition
The number partitions is also configurable. The default of 47 is adequate for small to medium dynamic cache grids because it gives an even balance of data and load across the grid. Increase the number of partitions for a larger grid. There is no absolute guidance for this, but to continue to have an even balance of data and load on the grid, aim to have at least five partitions per container.
For an alternative approach to sizing, where you need to deduce how many cache entries you can store in an existing or known eXtreme Scale grid capacity, see the Information Center
Error 404 - Not Found Error 404 - Not Found
The document you are looking for may have been removed or re-named. Please contact the web site owner for further assistance.