Vary caching policy

These are a series of test cases that compare the various cache replication sharing policies.

To run these tests required that the Trade application be modified to include an additional configuration parameter. This parameter was required because the Distributed Map API is used to set the sharing type when objects are inserted into the cache. The original version of Trade always set the type to not-shared.

A new JVM custom property, TRADE_REPLICATION_SHARING_TYPE, was defined. This property is set through the Administration console, Servers > Application Servers > server1 > Process Definition > Custom Properties.

The acceptable values are:

1: Not-shared
2: Shared-push
3: Shared-pull
4: Shared-push-pull

Table 1 explains the various sharing policies.

Table 1. Cache replication sharing policies for JVM
Value	Description
Not-shared	Cache entries for this object are not shared among different application servers. These entries can contain non-serializable data. For example, a cached servlet can place non-serializable objects into the request attributes, if the <class> type supports it.
Shared-push	Cache entries for this object are automatically distributed to the DynaCaches in other application servers or cooperating Java™ virtual machines (JVMs). Each cache has a copy of the entry at the time it is created. These entries cannot store non-serializable data.
Shared-pull (Deprecated)	Cache entries for this object are shared between application servers on demand. If an application server gets a cache miss for this object, it queries the cooperating application servers to see if they have the object. If no application server has a cached copy of the object, the original application server issues the request and generates the object. These entries cannot store non-serializable data. This mode of sharing is not recommended.
Shared-push-pull	Cache entries for this object are shared between application servers on demand. When an application server generates a cache entry, it broadcasts the cache ID of the created entry to all cooperating application servers. Each server then knows whether an entry exists for any given cache ID. On a given request for that entry, the application server knows whether to generate the entry or retrieve it from somewhere else. These entries cannot store non-serializable data.

These tests were run with a number of workload clients starting at 25 and increased by 5 until a total of 60 clients was reached.

All runs were done with the cache configuration described in Table 2.

Table 2. Cache definitions - Vary caching policy
DynaCache size	Caching mode	Servlet caching	Replication domain	Replication type
20000	Distributed map	Disabled	Entire domain	Not-shared
20000	Distributed map	Disabled	Entire domain	Shared-push
20000	Distributed map	Disabled	Entire domain	Shared-pull
20000	Distributed map	Disabled	Entire domain	Shared-push-pull

Figure 1 illustrates the throughput results with various caching policies. Figure 2 illustrates the CPU utilization results with various caching policies.

This figure shows the throughput results for the vary caching policy for caching policy not-shared, shared-push, shared-pull, shared-push-pull. — Figure 1. Throughput comparison with caching policy not-shared, shared-push, shared-pull, shared-push-pull

This figure shows the total CPU comparison for caching policy not-shared, shared-push, shared-pull, shared-push-pull. — Figure 2. CPU utilization comparison for caching policy not-shared, shared-push, shared-pull, and shared-push-pull

Figure 3 illustrates the CPU utilization results expressed relative to the not shared caching results, and taken from the perspective of: the z/VM® LPAR, the WebSphere® Application Server, the DB2® server, Apache Web servers, the Caching Proxy Server (CPS), and the firewalls.

This figure shows the changes in CPU utilization for caching policy shared-push, shared-pull, shared-push-pull relative to base (caching policy not-shared). — Figure 3. Changes in CPU utilization for Caching policy shared-push, shared-pull, shared-push-pull relative to base (caching policy not-shared)

Observations

In the three cases, shared-push, shared-pull and shared-push-pull throughput peaked at 55 workload clients. Overall CPU utilization continued to increase through 60 workload clients. The highest throughput was achieved with the not-shared case, the second highest was reached with the shared-push policy, the shared-pull and shared-push-pull cases had the lowest throughput.

The total CPU utilization for the four cases is very similar, varying by less than 3 %. Looking at each individual component shows that there is a significant increase in WebSphere CPU utilization for the shared-pull and shared-push-pull cases and corresponding decrease in CPU utilization on the other systems.

Conclusion

The not-shared cache replication policy produced the highest throughput. The throughput with shared-push's is lower than the not-shared case by approximately 5%. The throughput for shared-pull and shared-push-pull are both significantly lower while, the WebSphere CPU utilization has increased significantly. This indicates that for this workload, the overhead related with the share-pull and shared-push-pull cache replication mode is significant. However, even shared-pull does not improve the performance. There is more WebSphere cache replication activity with a corresponding decrease in throughput.

In this environment, using the not-shared policy produced the best results. It is more expensive to fetch from a peer cache than to obtain data from the database, because four caches have to be synchronized.