Varying Trade caching modes

Edit online

To study the impact of the different Trade caching modes on throughput, we ran several tests using the available Trade caching modes (No caching, Command caching, and DistributedMap caching). For these tests, we used the single WebSphere® Application Server setup (see Table 1).

Figure 1 shows the impact of the different Trade cache modes on throughput and with two and four virtual CPUs. The throughput maximum was reached with different numbers of clients, therefore the response time is not shown here because it is dependent on the number of clients. See Varying Trade clients for details.

Figure 1. Varying Trade caching modes - transaction throughput

tnwasext1

Observations

Enabling caching improves the throughput beyond a factor of 2. The best result was with DistributedMap caching. The throughput was nearly 2.7 times higher than without caching. The impact of the virtual CPUs is discussed in Varying virtual CPUs on the WebSphere Application Server.

To understand the impact of caching on our environment better, a deeper analysis of the system behavior where the WebSphere Application Server had two CPUs was done. We considered the following caching modes:
  • No Cache
  • Command caching
  • DistributedMap caching

The first analysis of these tests is shown in CPU utilization in Figure 2

Figure 2. Trade caching modes - CPU utilization

tnwasext2

Observations

The CPU utilization on the system is consistent with the throughput increase, except for the WebSphere Application Server, which is fully utilized in all scenarios. The UDB server had the highest CPU load when the caching was set to "No cache".

The chart shows that caching on the WebSphere Application Server reduces the CPU load on the UDB server. However, we see an increase of the CPU utilization between Command and DistributedMap caching, which is because of the increased overall throughput.

The total network I/O (received and sent from all interfaces involved) is shown in Figure 3.

Figure 3. Varying Trade cache modes - total network I/O per server

tnwasext3

Observations

Figure 3 shows that the caching proxy itself does not cache any requests and the network throughput scales very close to the Trade throughput. The WebSphere Load Balancer shows a very low load, because it was only involved when a new connection was established. The throughput on the WebSphere Application Server shows that the only caching happens between the Web server and the WebSphere Application Server and there was good caching efficiency. While the Trade throughput increased up to a factor of 2.7, the network throughput increased only 70%. The network throughput on the UDB server was also significantly reduced, but it increased with DistributedMap caching as shown with the higher Trade throughput.

Disk I/O appeared only for writes because there was almost no read activity on the disks during the measurement window. The only system which was expected to have read activity was the database. However, the database buffers were large enough that the data could be held there so there was no need to read it from disk. The write activity on the DB2® UDB server was caused by updates and log writes.

Conclusions

Enabling caching, either Command or DistributedMap, is highly recommended as long as data caching will not compromise data validity. All further measurements we ran were performed with DistributedMap caching. With no caching, there is a high CPU load on the DB2 UDB server.