Using WebSphere DataPower XC10 Appliance's simple data grid as a side cache for Java™ application can significantly reduce the load on backend systems by eliminating redundant requests to the backends, thereby improving the response time to the clients and increasing total system throughput. This article will highlight the side cache feature of the XC10.
This article reports compelling results on a benchmark where using a side cache with the XC10 improved client performance by:
- 364% over direct database access on read only scenario (scenario one)
- 202% on read (90%) and update (10%) scenario (scenario two)
- 184% on read (90%) and update/insert/delete (10%) scenario (scenario three)
CPU consumption on the database system was reduced from 51% to 1% in scenario one, from 52% to 16% in scenario two, and from 55% to 19% in scenario three.
Overview of WebSphere DataPower XC10’s side cache
IBM® WebSphere DataPower XC10 is designed to be the drop-in elastic cache for your enterprise infrastructure. The XC10 is the combination of the robust WebSphere DataPower hardware platform and state-of-the-art IBM distributed caching technology.
The XC10 supports three types of data grids:
- Simple data grids store simple key-value pairs.
- Session data grids store HTTP session management data.
- Dynamic cache grids store cacheable objects from applications that utilize the WebSphere Application Server dynamic cache APIs or container-based caching.
It is common for applications to make redundant calls, doing something over and over again on expensive backend systems, often to access data that does not change, such as user profiles. Applications that fit this description can benefit from using a simple data grid in the XC10 as a side cache. In this scenario, the application checks the cache every time that data is needed. If the value is not found (cache miss), the data is retrieved from the backend database and inserted into the cache. The next time that the data is needed, it is retrieved from the cache.
You can use simple data grids with WebSphere Application Server or with a standalone Java application. In both cases, the WebSphere eXtreme Scale client is installed on the Java Virtual Machine (JVM) to enable access to the XC10. The application uses the ObjectMap API to store key-value pairs of data in the cache, which reduces expensive database queries. The keys can be any existing Java type, such as String or Integer. The values can be any serialized object type.
Fantasy Sports XS
This benchmark, called Fantasy Sports XS, simulates a world-wide, sports web site where users create and manage a fantasy sports team and update personal preferences and options. An application of this scale and size presents significant challenge for administrators and developers because there is a need to scale in response to client demand increases. Utilizing the XC10 in these cases eliminates the need to scale the underlying database infrastructure as the XC10 tier scales with the application independently of the database.
Two benchmark configurations were used. First, a traditional OLTP topology is utilized where the application uses JPA persistence APIs to directly access a traditional database. Secondly, a simple data grid is introduced. The application checks the cache every time that data is needed.
Figure 1 shows the hardware topology and configuration.
Figure 1. Hardware topology
Application client configuration
The application client side of the Fantasy Sports XS benchmark can be thought of as the code that typically resides inside of a servlet that displays a rich user interface or inside of a standalone JVM for simplified testing. The term client, for the purposes of this benchmark, is not the end user that browses the web site from their web-enabled phone or laptop. It is, instead, the application code that is attached to the database and appliance.
The standalone JVM clients are hosted by IBM System x3755 with 16 AMD64 Opteron processors with 128GB of RAM and 1000 Mbps full duplex network adapter. During testing, the CPU utilization was around 98% and network utilization is around 100% for all three scenarios.
WebSphere DataPower XC10 configuration
The middle tier of the configuration is one IBM WebSphere DataPower XC10 Appliance, model-type: 7199-92X. It is deployed with Firmware 184.108.40.206. One simple data grid was used and replication was disabled. See the key configurations in Table 1.
Table 1. XC10 configuration
|Map Entry Locking||Pessimistic locking|
The backing datastore for Fantasy Sports XS resides on an IBM System x3755 with 16 AMD64 Opteron processors. The database for the Fantasy Sports XS application consists of 2 million unique users each with 1-4 Fantasy Sports Teams, which each in turn have 1 to 10 members. This database and user load is consistent with many of the leading fantasy sports sites in production today around the globe. To simulate a high performance disk array, we used a RAM disk to hold the database.
This section describes the details of the testing scenarios and results.
The baseline scenario for this article is the common case where the Fantasy Sports XS application is developed using the JPA programming model (OpenJPA in our scenario) to access the backend database system. As client load is ramped up against the Fantasy Sports XS web site, the database machine becomes the limiting factor for performance. In this case, the database dictates how many users can be supported as the application tier can be scaled out horizontally nearly infinitely given its stateless design, but its dependency on a single database system limits the scalability of the overall infrastructure.
Since we are postulating that our database system was the limiting factor for increasing capacity of the application and we find it difficult to grow that tier with more hardware to support additional users, we will offload the database by storing data in the XC10 by using it as a side cache. This scenario illustrates a significant improvement of overall throughput by over:
- 364% in scenario one
- 202% in scenario two
- 184% in scenario three
In addition, the load on the database is reduced from 51% to 1% in scenario one and from 52% to 16% in scenario two, and from 55% to 19% in scenario three.
Most of the benefit is the offloading of a significant amount of the read operations from the database and into the simple data grid. CPU consumption on the XC10 is 33% on scenario one, 20% on scenario two, and 18% on scenario three.
After warming up, read operations are mainly replied by the XC10 only. Update and delete operations are handled by both the XC10 and the database, and insert operations are handled by the database only. Thus, data integrity is maintained on the backend system. However, because of the reduction in read traffic, the database can effectively process those specific transactions to improve performance.
Figure 2 shows the throughput difference with and without a side cache.
Figure 2. Fantasy Sports XS transactions (Pessimistic Locking on Map)
Table 2 shows the details of the throughput difference.
Table 2. Fantasy Sports XS transactions details (Pessimistic Locking on Map)
|Baseline with JPA
|Side cache with
|Read (90%) and Update (10%)||9422||19036||202%|
|Read (90) and Update/Insert/Delete (10%)||9401||17305||184%|
Figure 3 shows the database CPU utilization on different scenarios.
Figure 3. Database CPU utilization
Table 3 shows the details the database CPU utilization.
Table 3. Database CPU utilization details
|Scenario||JPA only||Side cache|
|Read (90%) and Update (10%)||52%||16%|
|Read (90) and Update/Insert/Delete (10%)||55%||19%|
Figure 4 shows the XC10 CPU utilization on different scenarios.
Figure 4. XC10 CPU utilization
Table 4 shows the details of the XC10 CPU utilization.
Table 4. XC10 CPU utilization
|Read (90%) and Update (10%)||20%|
|Read (90) and Update/Insert/Delete (10%)||18%|
Table 5 shows the response time difference with and without a side cache. In the table, R is for Read operation, U is for Update operation, I is for insert operation, and D is for delete operation.
Table 5. Response time
Baseline JPA response |
Side cache |
response time (ms) – Pessimistic Locking
|Read (90%) and Update (10%)||7(R)/12(U)||3 (R)/23(U)|
|Read (90) and Update/Insert/Delete (10%)||7(R)/12(U)/15(I)/18(D)||4(R)/24(U)/21(I)/31(D)|
Update and delete operations in the side cache scenarios need to be handled by both the XC10 and the database and, thus, have higher response times than the baseline JPA scenario, which only needs to operate on the database. This is alleviated by doing asynchronous batching of update and delete operations to the database. Therefore, the application itself is serialized on the XC10 update and delete operations. But, this can carry the risk of data loss if the appliance crashed before the batch update occurred. That is the reason why we did not implement the benchmark in this way.
In this article, we presented benchmark testing showing that a simple data cache with WebSphere DataPower XC10 Appliance improved the Fantasy Sports XS scenario performance by 364% in scenario one, 202% in scenario two, and 184% in scenario three. CPU consumption on the database dropped significantly in all three scenarios.
Overall, the XC10 represents a significant leap forward in technology allowing administrators and developers to expand their existing infrastructure significantly, while not having to increase the size of their database systems. In fact, most will see reductions in database CPU and I/O consumption that allows for significantly expanded IT operations.
- IBM WebSphere DataPower XC10 Appliance developerWorks wiki
- Side Cache Usage Pattern developerWorks wiki
- WebSphere eXtreme Scale and DataPower XC10 Appliance developerWorks wiki
- developerWorks WebSphere DataPower zone
- WebSphere DataPower discussion forum