Vary caching mode

Edit online

In this test scenario, the Trade application was configured for: No caching, Command caching, and Distributed Map caching. For Command caching, an additional scenario was done with Servlet caching enabled. The objective was to determine which caching mode produced the highest throughput.

The standard configuration with WebSphere® Edge Services Caching Proxy Server was used. The client workload was scaled by increasing the number of users from 25 in increments of 5 until the throughput observed for the cluster peaked.

All runs were done with the cache configuration described in Table 1.
Table 1. Cache definitions - vary caching modes
DynaCache size Caching mode Servlet caching Replication domain Replication type
N/A No caching N/A N/A N/A
20000 Command caching Disabled Entire domain Not shared
20000 Command caching Enabled Entire domain Not shared
20000 Distributed Map Disabled Entire domain Not shared
Figure 1 illustrates the throughput results for this test scenario. Figure 2 illustrates the CPU utilization results for this test scenario.
Figure 1. Throughput comparison - No caching, Command caching, Command caching with Servlet caching, Distributed Map caching, WebSphere Edge Services Caching Proxy Server.
This figure show the base throughput for the Distributed Map Caching, WebSphere Edge Services Caching Proxy results.
Figure 2. CPU utilization comparison for - No caching, Command caching, Command caching with Servlet caching, Distributed Map caching.
This figure shows the base for client scaling of CPU utilization for Distributed Map Caching and WebSphere Edge Services Caching Proxy.
Figure 3 illustrates the CPU utilization results expressed relative to the Distributed Map caching results, and taken from the perspective of: the z/VM® LPAR, the WebSphere Application Servers, the DB2® server, Apache Web servers, the Caching Proxy Server (CPS), and the firewalls.
Figure 3. Changes to CPU utilization for No caching, Command caching, Command caching with Servlet caching, and Distributed Map caching, relative to base (Distributed Map caching)
This figure shows changes to CPU utilization for No caching, Command caching, Command caching with Servlet caching, Distributed Map caching, relative to base (Distributed Map caching)

Observations

With no caching being done at the WebSphere Application Servers, the CPU utilization on the database server increases to greater than 95% as more workload clients are added. In the CPU utilization charts above, it can be seen that DB2 utilization is significantly higher for no caching than with the other caching modes. Throughput reaches a maximum at 35 workload clients and starts to drop as more clients are added, while overall CPU utilization remains relatively constant.

When caching is enabled, the throughput is significantly higher in all modes than without caching, and it increases from 25 clients to at 50 or more clients. The CPU load is only a little bit higher.

With Command caching, maximum throughput was reached at 50 workload clients and then decreased or remained the same. Enabling Servlet caching with Command caching results in a throughput peak at 55 workload clients. The maximum throughput obtained is less than what was seen for Command caching without Servlet caching. Adding workload clients above 55 resulted in the throughput tailing off or remaining the same. For both, overall CPU utilization continues to increase as more workload clients are added. Both Command caching and Command caching with Servlet caching have higher WebSphere CPU utilization then Distributed Map caching.

Distributed Map caching achieves the highest throughput at lowest CPU load.

Conclusions

In the no caching case, it appears that throughput performance is being constrained by DB2, and the CPU cost for the transactions is much greater.

The effects of enabling command caching is quite dramatic, DB2 CPU utilization has deceased and throughput has almost doubled. The CPU utilization of the four WebSphere Application Servers in the cluster has also increased, but only by approximately 10% per server.

The Trade file cachespec.xml has a servlet section, so Servlet caching with Command caching was enabled. This combination did not result in a throughput improvement. The addition of Servlet caching did not improve the overall throughput; it had a small negative effect on throughput, a decrease of approximately 6%. There is a slight increase in WebSphere Application Server CPU utilization from that observed for Command caching.

Distributed Map caching is handled in application code in the Trade application. An investigation of this code indicated that enabling Servlet caching with Distributed Map caching would not result in any additional improvement, because Servlet caching and Distributed Map caching cache the same objects.

As can be seen in Figure 3, the highest throughput was achieved with Trade caching mode set to Distributed Map. Distributed map caching resulted in a throughput increase of more than double what was seen with no caching. It also shows a 6% increase over Command caching, and the overall CPU utilization is the lowest. In particular, the total CPU utilization of the WebSphere Application Servers is lower than all other modes.

Any of the caching options produced a significant performance improvement over no caching. It is recommended that some form of caching be used.

Because Distributed Map caching produced the highest throughput, all subsequent measurements were performed with this option.