Performance advantages of using WebSphere DataPower XC10 Appliance as a side cache for a Java application

This article reports results on a benchmark study where using a side cache with WebSphere® DataPower XC10 Appliance significantly improved client performance over direct database access for read only, read and update, and read and update/insert/delete.


Gary Z. Zeng (, Software Developer, IBM

Gary Zeng is a Software Developer who works on WebSphere DataPower XC10 and eXtreme scale performance analysis.

David J. Strite (, Staff Sofware Engineer, IBM

Photo of David J. StriteDavid Strite is a Software Engineer on the WebSphere Performance Engineering team, focusing on WebSphere Extreme Scale and WebSphere DataPower XC10.

07 November 2012


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
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 One simple data grid was used and replication was disabled. See the key configurations in Table 1.

Table 1. XC10 configuration
Configuration type Value
ttlEvictorType None
Replication Off
Map Entry Locking Pessimistic locking

Database configuration

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.

The results

This section describes the details of the testing scenarios and results.

Baseline scenario

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.

Side cache

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)
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
throughput (tx/sec)
Side cache with XC10
throughput (tx/sec)
Percent improvement
with XC10
Read 10189 37134 364%
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
Database CPU utilization

Table 3 shows the details the database CPU utilization.

Table 3. Database CPU utilization details
Scenario JPA only Side cache
Read 51% 1%
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
XC10 CPU utilization

Table 4 shows the details of the XC10 CPU utilization.

Table 4. XC10 CPU utilization
Scenario Side cache
Read 33%
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
Scenario Baseline JPA response
time (ms)
Side cache
response time (ms) – Pessimistic Locking
Read 8 4
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.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Performance advantages of using WebSphere DataPower XC10 Appliance as a side cache for a Java application