Home


Test scenario

WebSphere Commerce implements several business models, such as B2C, B2B, and hosting, with user behavior differing widely by model.

In our tests, we use a B2C (consumer direct) store. To reduce the amount of preparatory work, we use a custom version of the WebSphere Commerce consumer direct starter store with the data described here.

For a B2C e-commerce site, the typical workload is dominated by customer activities. To reflect that, we assumed the following workload distribution in our tests:

Users:

Buy ratio:

Errors on logon

To assess think time, analyze your Web server activity logs. The longer the think time, the more concurrent users it takes to create the same workload. In the context of benchmarking, this means that, to get the same amount of workload for the benchmark, we require more machines that simulate end users, because the maximum number of concurrent users that a single machine can simulate is limited. Conversely, for our test purposes, we can reduce the think time in order to reduce the number of concurrent users and the number of machines required to simulate them.


Think times (seconds)

Web action Think time Web action Think time
Select shipping address 5 View order summary 10
Add shipping address 10 Add payment info 10
Display category 3 Display product 3
Log off 2 View shipping method 5
Log on 5 Display top category 5
Go to log on page 0 Visit store front 0
Add item to cart 5 Register user 10
View billing address 5 Go to register page 0
Process order 5    


100 concurrent users using cachespec.xml

In the previous test, we saw a considerable performance improvement brought on by DynaCache. We also saw that the category display page now consumes most of the total time, and the CPU usage on both WebSphere Commerce servers is up. Dynamically caching other pages should help us improve response time and reduce resource usage. In this next test, we use the sample cachespec.xml file provided with the WebSphere Commerce consumer direct starter store, which enables caching of a number of other pages (including the category display page) as well as WebSphere Commerce commands.


Results of the test

  CPU usage Min JVM
heap usage
Hard disk
usage increase
Commerce server 1 18.74% 450MB  
Commerce server 2 18.01% 420MB  
Database server 8.17%   58MB
Web server 6.36%    


Resource usage with 100 users and sample cachespec.xml

Web action Avg response time Count Total time
Overall 0.238 289,004 68782.952
Select shipping address 0.385 3,596 1384.46
Add shipping address 0.276 2,609 720.084
Display category 0.197 130,859 25779.223
Log off 0.292 6,644 1940.048
Log on 0.355 3,683 1307.465
Go to log on page 0.305 3,683 1123.315
Add item to cart 0.82 9,097 7459.54
View billing address 0.787 7,381 5808.847
Process order 0.86 810 696.6
View order summary 1.21 1,646 1991.66
Add payment info 0.784 811 635.824
Display product 0.129 43,591 5623.239
View shipping method 0.467 7,372 3442.724
Display top category 0.127 43,648 5543.296
Visit store front 0.157 16,864 2647.648
Register user 0.433 3,355 1452.715
Go to register page 0.332 3,355 1113.86

Total time for URL actions fin test with 100 users and sample cachespec.xml:

We see a significant drop in CPU usage for both the WebSphere Commerce and database servers, as well as an increase in the total number of pages visited in 3 hours, from 210,572 to 289,004. We still see the category display page dominating the total time column. However, this results largely from the sheer number of hits it gets (~50% of total hits); the response time has gone down from 2.496 seconds to 0.197 seconds.


IBM Sales Center

The IBM Sales Center architecture is comprised of the IBM Sales Center client, WebSphere Commerce server and a messaging architecture.

A data model is used to cache business objects on the client. The default IBM Sales Center data model contains model objects that represent the operator, customers, orders, products, and other commonly used objects. If a valid data model instance (data object) is not available, a service request is sent to the server to retrieve the information to create or update the data model in the client.


Messaging architecture


IBM Sales center architecture

The interactions are...

  1. The IBM Sales Center client performs a service request.

  2. The service request handler prepares a Business Object Document message.

  3. A message is sent from the client to the host machine.

  4. The message mapper receives the message and maps the Business Object Document to a WebSphere Commerce BOD command.

  5. The WebSphere Commerce BOD command is invoked.

  6. The WebSphere Commerce BOD command calls a WebSphere Commerce Controller command, which may call one or more task commands.

  7. The reply or response builder constructs the response BOD.

  8. A response is returned to the client machine.

  9. The request handler receives and handles the response BOD.


Scheduled invalidation

We have discussed invalidating cache entries with time-based elements or through a combination of command-based invalidation using dependency and invalidation IDs. These entries are invalidated using command-based invalidation rules.

Another way to invalidate cache content is by making use of the WebSphere Commerce scheduler, which periodically invalidates cache content based on entries in the CACHEIVL table, shown in Figure | -2, using the DynaCacheInvalidation command. After installing WebSphere Commerce APAR IY886561 it is possible to invalidate cache entries after some future point in time. That is, you can specify a future time to begin to apply invalidation rules. For example, if you are planning to run a time-limited e-Marketing campaign, at the time you develop the e-Marketing campaign Web pages, you can also specify when the pages are to be evicted from the cache at the end of the campaign.

Figure 3-2 CACHEIVL table definition

The frequency at which the DynaCacheInvalidation command is called is set by the WebSphere Commerce scheduler. To modify the frequency, launch the WebSphere Commerce Administration Console and select:

Figure 3-3 Accessing the scheduler

The WebSphere Commerce scheduler runs the DynaCacheInvalidation command at a set interval. This command processes the entries in the CACHEIVL table...

The clearall string value in the TEMPLATE or DATA_ID columns of the CACHEIVL table is used by DynaCacheInvalidation to clear the cache using the DynaCache invalidation API (clear).

If the TEMPLATE column is set, then the DynaCacheInvalidation command calls the DynaCache invalidation API (invalidateByTemplate) and uses the name as the template ID. If the clearall string value (which is case insensitive) is found in the TEMPLATE column, then the DATA_ID column is ignored and the DynaCacheInvalidation command clears the cache. If the TEMPLATE column is not empty, the command invalidates using the template ID, ignoring the DATA_ID column.

If the DATA_ID column is set and the template name is not set, then the DynaCacheInvalidation command calls the DynaCache invalidation API (invalidateById) and uses the DATA_ID as the dependency ID of the cache entries to invalidate. If the TEMPLATE column is empty and the clearall string value is found in the DATA_ID column, then the command clears the cache.

When the DynaCache invalidation API is called, it invalidates the cache entries.

Create database triggers to populate the CACHEIVL table. Use the sample triggers in Example | -8 to detect and react to changes in the Store and Catalog pages. This list is only a subset of several possible triggers, and is not comprehensive. Ensure that the invalidation IDs have matching dependency ID values for the cache entries you want to invalidate.

Example 3-8 Catalog and store triggers

CREATE TRIGGER cache_1
AFTER UPDATE ON catalog
REFERENCING OLD AS N FOR EACH ROW MODE DB2SQL
INSERT INTO cacheivl (template, dataid, inserttime)
(SELECT NULLIF('A', 'A'),  'storeId:' ||  RTRIM(CHAR(storecat.storeent_id)), CURRENT TIMESTAMP
   FROM storecat
  WHERE storecat.catalog_id = N.catalog_id);

CREATE TRIGGER cache_2
AFTER UPDATE ON storecat
REFERENCING NEW AS N FOR EACH ROW MODE DB2SQL
INSERT INTO cacheivl (template, dataid, inserttime)
(SELECT NULLIF('A', 'A'),  'storeId:' || RTRIM(CHAR(N.storeent_id)), CURRENT TIMESTAMP
   FROM catalog
  WHERE catalog.catalog_id = N.catalog_id);

CREATE TRIGGER cache_3
AFTER UPDATE ON cattogrp
REFERENCING NEW AS N FOR EACH ROW MODE DB2SQL
INSERT INTO cacheivl (template, dataid, inserttime)
(SELECT NULLIF('A', 'A'),  'storeId:' || RTRIM(CHAR(storecat.storeent_id)), CURRENT TIMESTAMP
   FROM storecat
  WHERE storecat.catalog_id = N.catalog_id);

CREATE TRIGGER cache_4
AFTER UPDATE ON staddress
REFERENCING NEW AS N FOR EACH ROW MODE DB2SQL
INSERT INTO cacheivl (template, dataid, inserttime)
(SELECT NULLIF('A', 'A'),  'storeId:' || RTRIM(CHAR(storeentds.storeent_id)), CURRENT TIMESTAMP
   FROM storeentds
  WHERE storeentds.staddress_id_cont = N.staddress_id);

1Obtainable as an efix from IBM service - likely to be shipped in 6.0.0.2, 5.6.0.7 and 5.6.1.3.


Execution and results

As stated at the opening of the Benchmarking example section, the purpose of our tests is to create a benchmark for a WebSphere Commerce system with DynaCache, as well as to show performance improvements that DynaCache brings. As discussed in Obtaining the baseline results and measuring improvements, we therefore need a baseline test without DynaCache and a test with the finalized parameter set, reflected by the cachespec.xml descriptor, to serve as the new DynaCache baseline for any possible changes at a future time. Sometimes, we also require additional tests, for example, to confirm that we get performance benefit from such changes or to investigate system behavior under a different set of circumstances.

We ran four tests in preparation of this book:

100 concurrent users without DynaCache

100 concurrent users with caching the product display page only

100 concurrent users with the cachespec.xml file provided as part of the WebSphere Commerce consumer direct starter store

200 concurrent users with the cachespec.xml file provided as part of the WebSphere Commerce consumer direct starter store

We ran each test for 3 hours, using the JVM heap size of 1GB and identical scenarios, ratios, and think times (see Test data set and scenario).

Distributed Caching for Performance and Scalability: WebSphere DataPower XC10 Appliance


The WebSphere DataPower XC10 Appliance caches data from data servers for high-speed access by applications. The cache acts as a cushion for the data servers by storing frequently used data, thus reducing the amount of read and write accesses to the data servers. This caching tier is situated between the application server tier (which hosts the business applications) and the data tier. The cache is easily expandable and can store and manage large amounts of data securely with integrity and with consistent performance.

The WebSphere DataPower XC10 Appliance is designed for rapid drop-in deployment and features...

With multiple XC10s, you can build in fault tolerance for your data, ensuring high availability.


Caching data close to applications in an expandable data grid

The WebSphere DataPower XC10 Appliance is capable of holding one or more data grids, which store data using loosely coupled cooperative caches.

Each grid is associated with a specific application or set of applications. The WebSphere DataPower XC10 Appliance contains a 160 GB of storage for grid capacity. If this capacity is not enough, you can expand the grid by adding one or more appliances to the configuration, which creates a collective of appliances that hosts data. This capability of grouping appliances allows you to increase cache capacity and data throughput quickly and easily as needs grow.

Types of grids include:

Session data grids Used by WAS to manage data used during the course of a web session.
Dynamic cache grids are Used by the dynamic cache service in WAS to store frequently accessed web pages.
Simple data grids Hold data that is accessed directly by applications.


Using drop-in scenarios with no required code changes

The WebSphere DataPower XC10 Appliance complements the WebSphere Application Server family of products by including two drop-in scenarios to provide a distributed caching platform for WebSphere business applications. These drop-in scenarios are designed to run with any WebSphere product that is based on WebSphere Application Server V6.1 and V7.0.

In this section, we describe these two scenarios:


Caching user session data

Many web applications use the HTTP session state management features provided by JEE application servers. Session state management allows the application to maintain user information and the state of the session for the period of a user's interaction with the application. The traditional example for this scenario is a shopping cart, where information about intended purchases is stored until the shopping session is completed.

To support high-availability and failover, the state information must be available to all application servers, which application servers typically achieve by storing the state information in a shared database or in the application server's memory. In the latter case, session data is sent to each application server to keep the data in sync.

When session data is stored in a shared database, scalability is limited by the database server. The disk I/O operations are an expensive performance cost to the application. When the transaction rate exceeds the capacity of the database server, the database server must be scaled up.

When session data is kept in memory and replicated between application servers, the limits to scalability vary depending on the replication scheme. Commonly, a simple scheme is used in which each application server holds a copy of all user session data. In this scheme, the total amount of state information cannot exceed the available memory of any single application server. Memory-to-memory replication schemes often trade consistency for performance, meaning that in cases of application server failure or user sessions being routed to multiple application servers, the user experience might be inconsistent and confusing.

With the WebSphere DataPower XC10 Appliance, session data is kept in the grid, providing high-speed access to the data from all application servers. If one server goes down, the session can be continued on another server with the session data kept intact. Configuration is simple with support for the WebSphere DataPower XC10 Appliance built into the application installation process. You can specify an existing grid or create a new grid directly from the WebSphere Application Server console.

As a practical example of this type of scenario, consider an insurance company that provides an application on its internet site that allows customers to get a price quote on car and home insurance. As potential customers using the site navigate through a series of pages, they enter information about the assets that they want to ensure, and they make selections regarding coverage. This information is collected and stored by the web application as session data to be used to create the price quote. At the end of the process, the user reviews the information and submits it for processing.

In this scenario, user performance is critical, because users tend to become frustrated with slow movement between pages. While the default in-memory session management that was used by the application serving environment worked, the replication that was required to keep the data synchronized for availability purposes put a load on the application servers and caused performance delays for the user. In addition, the accumulation of session data due to the length of time that it took users to complete the application became a burden on the memory of the application servers.

By moving this session data to a collective of XC10 appliances, several critical improvements occurred. The response times to the user became more consistent and faster. Memory was freed for executing the application rather than storing data. Synchronization of data between the application servers was no longer necessary, which reduced the load on the application servers. Reliability was also improved. The collective contained replicas of the data so that if an application server went down, the data was not lost with it. The remaining servers could continue the session without losing the data.


Caching dynamic web pages

Many web-based applications use dynamic page generation techniques for pages that rarely change, such as product details or information about corporate policies. Application servers generally provide at least an in-memory cache to store the generated output the first time that the page is rendered in order to save the processing work and back-end system load for subsequent requests.

The WebSphere Application Server dynamic cache service stores the output of dynamic web pages for future use in memory, using replication to share the data among application servers. When the in-memory capacity is reached, the data is off-loaded to shared disk and disk access time becomes an important factor in application performance. Faster disk technologies, such as Storage Area Networks (SANs), are often used to improve performance.

The XC10 provides a drop-in replacement for the dynamic cache service.s default cache provider. The XC10 stores cached data in a grid, allowing the size of the cache to expand to the sum of all available memory in XC10s in the grid. Cached data is readily available, making the application.s performance more reliable and eliminating load spikes to back-end systems as applications are scaled. The XC10 dynamic cache service provider can compress the contents of the cache to get the most from the memory available.

As an example of this type of scenario, consider an airline that posts information about current and future flights on its website. The site is used by customers who are looking for available flight information, by passengers checking to see whether flights are delayed or canceled, and by others checking for flight arrival information. Users can view a list of flights by date, select a specific flight for more information, or select multiple flights for comparison.

The flight information is stored in a database and accessed by the web application. While the information about flights for the current day tends to change frequently, the data for future flights is fairly static. Dynamic caching is used to store the data that is frequently accessed but infrequently changed, thus reducing the time and resources that are required to build the web pages.

The high volume of requests, however, puts a significant load on the application servers, increasing response times and making the performance erratic. By introducing a collective of XC10 appliances, the company offloaded the memory and computing resources that are required to maintain the cache from the application servers, increasing both throughput and performance.


Use a simple cache for application data

Applications can use a data grid in the XC10 as a simple cache. The application checks the cache every time that data is needed. If the value is not found (cache miss), then the data is retrieved from the backend database and inserted into the cache. The next time that data is called for, it is retrieved from the cache.

Simple data grids can be used with WebSphere Application Server or with a stand-alone Java application. In both cases, the WebSphere eXtreme Scale client is installed on the JVM. The application accesses the data grid using the ObjectMap API. The WebSphere eXtreme Scale client is available for download through the IBM Support Portal.

While this type of use requires some alterations to your application code to take advantage of the data grid, it is an excellent way to provide high-speed caching.

As an example of this type of scenario, consider an animal rescue organization that has a website where potential adopters can view information about the animals that are available for adoption. The information about each animal is stored in a database and is updated on a regular basis with the adoption status, new pictures, and age and health information. These updates are not frequent, but users viewing the site need to know whether an animal is already adopted.

Accessing the database with every request has proven to be expensive in terms of response time. When the volume of requests is high, the database becomes a bottleneck, reducing performance significantly. Use of the site (and adoptions) dropped as these problems grew.

The application was modified to use the WebSphere DataPower XC10 Appliance as a simple cache. When a user requests information about an animal, the data is retrieved from the database and is cached for future retrievals. Caching the data significantly improved performance and provided the opportunity for future growth.


Securing your data

Much of the security functionality offered by the WebSphere DataPower XC10 Appliance to protect the data in the grid is built into the construction of the appliance. Additional security settings are included to provide security options for accessing the user interface.

The WebSphere DataPower XC10 Appliance includes the following security features:


Avoiding downtime (fault tolerance)

When you have grouped multiple appliances into a collective, the collective lowers the risk of data loss through the automatic replication of data. If an appliance housing the primary data grid fails, a replica on another appliance in the collective is promoted automatically to be the primary. Multiple replicas are supported and are transparent to the application that uses the WebSphere DataPower XC10 Appliance to store data. This fault tolerance setup provides continuous availability in the event of the loss of one of the appliances. The grid becomes self-healing, in that failures are detected and managed automatically.


Managing grids and collectives with ease

The WebSphere DataPower XC10 Appliance provides a web-based console that allows you to create, manage, and monitor data grids and collectives. You can also use the web interface to manage users and user groups for your appliance. The console provides simple, intuitive steps to create everything that get started and provides guidance to help you complete each task.


Creating grids

Creating a grid is as simple as clicking a button and providing a name for the grid. Modifiable settings for the grid are minimal, including only security and replica settings. Figure 5 shows the window to set dynamic cache properties.


Monitoring grids

The console also provides real-time monitoring of the performance and health of the grids. Both summary and detailed reports are available. You can see the number of entries in the grid, average throughput and transaction times, used capacity, and other valuable information that can help you monitor the grids.


Integrating with WebSphere Application Server

The WebSphere eXtreme Scale client code, installed into the WebSphere Application Server environment, seamlessly integrates the WebSphere DataPower XC10 Appliance with the application server environment. The option to use the XC10 as the dynamic caching provider is available from the administrative console, and options are built into the application installation process to allow you to select a data grid in the XC10 for session persistence.


Comparing the WebSphere DataPower XC10 Appliance to the WebSphere eXtreme Scale software offering

WebSphere eXtreme Scale software has long been recognized as the scalable caching mechanism of choice in WebSphere Application Server environments. Like the WebSphere DataPower XC10 Appliance, WebSphere eXtreme Scale supports a dynamic grid infrastructure with support for substantial scale outs. Both offer high performance for extreme transaction processing.

What are some of the most prominent differences? Where the WebSphere DataPower XC10 Appliance stores cached data in the appliance, WebSphere eXtreme Scale builds grids using JVMs. In addition, whereas the WebSphere DataPower XC10 Appliance is designed for the three caching solutions (dynamic cache, session management, and simple side cache), WebSphere eXtreme Scale supports these scenarios and offers additional flexibility in the type of caching that it supports and how the cache is loaded.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


+

Search Tips   |   Advanced Search