Performance and scale are critical in the competitive world of web retail. A website that gets bogged down under high volume can result in discouraged customers and lost sales. Planning for peak load is key to ensuring that customers stay happy, stay focused, and keep shopping. By combining the robust capabilities of IBM WebSphere Commerce with the performance and scale of IBM WebSphere eXtreme Scale, your retail websites can ensure a consistent and satisfying experience for your customers.
WebSphere Commerce is provided as a Java™ EE application running on the powerful and robust IBM WebSphere Application Server platform. As such, WebSphere Commerce already fully utilizes WebSphere Application Server scalability and performance features, such as clustering and dynamic caching. The dynamic cache service is a feature of WebSphere Application Server that provides an in-memory cache to improve performance by eliminating the need to regenerate dynamic web content that has not recently changed. Content is stored in the cache and shared until it is invalidated.
WebSphere Commerce websites make extensive use of the dynamic cache service to reduce database roundtrips and therefore gain performance improvements. Entire pages (JSPs), page fragments, and commands are stored in the dynamic cache along with user related object data. There are opportunities to further customize the types of elements that are stored and the length of time they remain in dynamic cache.
WebSphere eXtreme Scale includes support to serve as a dynamic cache provider and can therefore be used to provide the dynamic cache for any WebSphere configuration. This article leverages this provider to support the dynamic cache needs of WebSphere Commerce. This is a relatively simple configuration change that can be accomplished using the WebSphere Application Server administration console. You do not have to change the WebSphere Commerce application or any management tools that you use in your environment today if they rely upon the existing dynamic cache APIs.
This article provides a concise description of the changes necessary to move from a WebSphere Commerce configuration that uses the default dynamic cache implementation to one that uses a remote IBM WebSphere eXtreme Scale dynamic cache implementation. This article assumes familiarity with WebSphere Commerce and its use of the dynamic cache service. A brief overview of WebSphere eXtreme Scale is presented here, along with a description of the benefits it can provide in a WebSphere Commerce environment.
For detailed descriptions of all aspects of the options available in this configuration, refer to the product documentation, the IBM Redbook Scalable, integrated solutions for elastic caching using WebSphere eXtreme Scale, and the other Resources listed with this article.
For the scenario used in this article, WebSphere Commerce is running as a single server installation with the Madisons starter store archive (included with WebSphere Commerce) published for testing. A standalone WebSphere eXtreme Scale image runs on the same host with one catalog server and two container servers. A remote topology was created for the cache store that indicates it is outside of the WebSphere Commerce JVMs. In this configuration, the actual data grid is running as a standalone WebSphere eXtreme Scale implementation, but it could have just as easily been configured to run within WebSphere Application Server images. This is a simplified environment, but it will do well to illustrate the steps required in the WebSphere admin console even for more complex configurations. The only significant difference in a more complex configuration would be the need to perform these identical steps on each of the WebSphere Commerce servers or clusters.
Figure 1 shows the high-level structure of the configuration of the primary components. The WebSphere Commerce server is configured to use the dynamic cache provider delivered with WebSphere eXtreme Scale. This cache provider connects to the grid using the catalog server that is defined to gain access to the data grid. The data grid is registered with the catalog server. Given that WebSphere Commerce is already configured to use the dynamic cache, you only need to change the dynamic cache provider to gain the benefits of WebSphere eXtreme Scale.
Figure 1. High level design
The scenario described in this article was created with these product versions:
- WebSphere Commerce V184.108.40.206
- WebSphere Application Server V220.127.116.11
- WebSphere eXtreme Scale V7.1 plus cumulative fix 1
Although not covered in this article, the following minimum product levels should support a similar environment, although there are some configuration differences:
- WebSphere Commerce V18.104.22.168 with WebSphere eXtreme Scale V22.214.171.124
- WebSphere Commerce V126.96.36.199 with WebSphere eXtreme Scale V7.0 iFix 4 (plus fix PM21272)
Also, the example described here was implemented on a Linux® server. If you are using a Windows® server use the *.bat files rather than *.sh whenever scripts are referenced and modify path statements as necessary.
See the product documentation and the Redbook referenced above (section 6.3.3 WebSphere eXtreme Scale prerequisites and following) for more details on configuration differences when using versions other than those specified for this article.
Planning for your environment
Careful consideration should be given to your system environment. This article utilizes a simple configuration for clarity but an actual production environment is much different. For example, this article uses the default number of partitions set in the dynacache-remote-deployment.xml configuration file, just one catalog server, and two container servers. In a production environment, you should consider the maximum number of entries to be stored in your dynamic cache, the size of the records, your WebSphere eXtreme Scale replication policy, and several other factors when determining the number of partitions and container servers. You must also consider the system availability requirements when considering the number of WebSphere eXtreme Scale catalog servers to allocate (see Resources).
When leveraging WebSphere eXtreme Scale for the dynamic cache provider, it is also important to consider the network bandwidth between the various components of your environment. After you configure the dynamic cache to utilize WebSphere eXtreme Scale, all cache access will be via the network rather than using local cache. It is therefore imperative to ensure high bandwidth connectivity between the WebSphere Commerce servers and the WebSphere eXtreme Scale container servers to minimize network latency. If care is not taken when considering the connectivity of these components, the end result might be less performant than the former configuration under light load.
Why use WebSphere eXtreme Scale with WebSphere Commerce
There are many benefits to using WebSphere eXtreme Scale as the dynamic cache provider within a WebSphere Commerce environment. Perhaps the most important benefit is the elimination of duplicate cache instances and the required invalidation traffic that is necessary to keep them synchronized.
In a default dynamic cache implementation, a copy of the cache is maintained in each WebSphere Commerce server and invalidation processing is necessary to keep these caches in sync. In a large system, this can require a significant amount of memory and invalidation chatter. As you can see, each WebSphere Commerce server contains the same set of cached data. Depending upon the invalidation logic used, each server might not have a complete copy of the cache, but over time a steady state is typically reached as each server cache grows to contain nearly identical copies of the cache. Invalidation logic is necessary between the servers to synchronize the data, as shown in Figure 2.
Figure 2. Default dynamic cache
This works well for small cache requirements and can support larger cache requirements using disk offload to enable a cache much larger than possible with a memory only cache. However, this model begins to break down as transaction volumes increase and additional servers are added to accommodate the increased traffic. The addition of servers means the addition of invalidation traffic. Similarly, growth in the cache brings increased disk demands that could require expensive SAN solutions. As scale increases, a saturation point is quickly reached with a bottleneck on the cache disk offload, the invalidation traffic, or both. Also as each new server is added, its cache must warm up which is an expensive operation placing additional stress on the system resources.
Figure 3 shows a similar scenario with a remote topology deployment of WebSphere eXtreme Scale elastic caching. There is a shared copy of the cache that can be utilized by all of the WebSphere Commerce servers. The invalidation traffic is eliminated between the WebSphere Commerce servers as they no longer have the responsibility to manage the cache. It is true that all access is via the network but this can be mitigated by several optimizations provided in WebSphere eXtreme Scale such as data compression. The elastic cache solution can be easily scaled by adding more JVMs to support even larger cache requirements. Resiliency is provided by both synchronous and asynchronous replication that can be configured to meet your particular needs.
Figure 3. WebSphere eXtreme Scale dynamic cache
A Commerce solution benefits from this shared, elastic cache in many other ways:
- There is no need for expensive SAN disk arrays for increased disk demands as with a typical disk offload.
- WebSphere eXtreme Scale runs on commodity boxes and the software makes them fully fault tolerant.
- WebSphere eXtreme Scale provides perfect linear scaling – just add another box to the grid.
- Each cache entry is generated only once – not once per server – saving CPU and disk I/O.
- Cache entries are invalidated only once per cluster rather than per server in the cluster and subsequently regenerated only once for all servers in the cluster to share, drastically cutting disk I/O and CPU requirements.
- As servers are added, cache warm-up is faster because of the shared cache.
That's a long list of benefits with very little downside and it can all be unleashed with just a few configuration changes.
Using the default dynamic cache provider
Before you begin to change anything for WebSphere eXtreme Scale, it will be helpful to review the current configuration. The configuration for this article was created using the WebSphere Commerce quick install, which lays down a complete WebSphere Commerce image on a single machine. The resulting configuration is not intended for production use, but it is fine for the purpose of this article. The Madisons store sample provided by WebSphere Commerce is installed to be used as a tool to populate the dynamic cache. Let’s look at this current configuration using the default dynamic cache provider.
- Start the Integrated Solution Console (ISC) by doing one of the following:
- In a browser, go to
http://<hostname>:9060/ibm/console. Depending on your installation, the hostname and the console port could be different.
- Enter your application server administrative user ID and password (if required), and click Log in.
- In a browser, go to
- In the navigation tree, click on Servers to expand the Server
Types menu. Select WebSphere application servers to display a list of all application servers in the right panel as shown in Figure 4.
Figure 4. Application servers
- In the right panel, select server1 (or the server that you have used for your WebSphere Commerce installation) to view configuration details of this server (Figure 5).
Figure 5. Server view
- Expand Container Services under Container Settings and then click
Dynamic cache service, as highlighted in Figure 6.
Figure 6. Container services
- This panel displays the current setting of the cache provider. Notice that the
Cache provider is set to Default dynamic cache (Figure 7). If you have already augmented your application server profile with the WebSphere eXtreme scale client, you can click on the drop-down list and see the alternative choice of WebSphere eXtreme Scale.
Figure 7. Default dynamic cache provider
- Click on server1 again, either by following steps 2 and 3 above or simply by clicking on server in the breadcrumb trail at the top of the right panel, as shown in Figure 8.
Figure 8. Breadcrumbs
- From the server1 details panel, expand Java and Process Management under
Server Infrastructure and select Process definition (Figure 9).
Figure 9. Process definition
- Click on Java Virtual Machine under Additional Properties (Figure 10).
Figure 10. Java Virtual Machine
- Under Additional Properties, select Custom properties on the panel shown in Figure 11.
Figure 11. Additional Properties
- Observe the set of properties defined that pertain to com.ibm.ws.cache*. These properties are used to configure the dynamic cache behavior. You will add additional properties to this collection as you configure the image to leverage WebSphere eXtreme Scale. Your view should be similar to that shown in Figure 12.
Figure 12. Custom properties
- Next, let’s see how this behaves with the test store application, Madisons.
You can administer WebSphere Commerce sites using the admin console from an
Internet Explorer browser (
http://<hostname>:port/adminconsole). (Internet Explorer is currently the required web browser for the WebSphere Commerce administration console.) For this example, the administration console is used to publish the Madisons store site sample. After the site is published, you can access it from any web browser using
http://<hostname>/webapp/wcs/stores/Madisons/index.jspto present the main store page, shown in Figure 13.
Figure 13. Madisons online shopping
As you click on some of the categories and images, you’ll see that Madisons is a very nice sample of a retail website and does a good job of demonstrating the capabilities of WebSphere Commerce. By clicking on various pages, products, and descriptions you are generating web content that is being saved in the dynamic cache for subsequent reference by you and other shoppers. (Be aware that the dynamic cache configuration has expiration logic built into the application using cachespec.xml files in the WARs. Many of the default values have a timeout of 5 minutes of being inactive. Therefore, even as you populate instances in the cache many of these instances will timeout after 5 minutes.)
- After using the Madisons sample for some online browsing and shopping, take a
look to see what is populated in the cache. You can do this using the Extended
Cache Monitor, which is a technology preview that is an extension of the cache monitor
supplied with WebSphere Application Server. The extensions enable it to better manage multiple dynamic cache providers. It also provides a selection of MBean statistics and enables you to view object cache contents.
Enter this URL into a web browser to access the Extended Cache Monitor (your port may be different depending upon your installation):
http://<hostname>:9061/cachemonitor. You should see the initial cache monitor screen as shown in Figure 14.
Figure 14. Extended Cache Monitor
Immediately after some activity using the Madisons store sample, the cache monitor Cache Contents page should show some entries for the category displays that include “TopCategoriesDisplay” in the Cache ID (Figure 15).
Figure 15. Extended Cache Monitor cache contents
Installing WebSphere eXtreme Scale
This example uses WebSphere eXtreme Scale V7.1, which can be installed in either a new directory for a standalone deployment or it can be installed on top of a WebSphere Application Server cell for an integrated deployment. The scenario described here has WebSphere eXtreme Scale installed as a standalone deployment. The WebSphere eXtreme Scale client is also installed on the WebSphere Commerce deployment. The following high level steps were followed to install WebSphere eXtreme Scale for this exercise:
- Install WebSphere eXtreme Scale as a standalone product.
- Install the WebSphere eXtreme Scale client on the WebSphere Commerce deployment by running the installation again, selecting the WebSphere Commerce installation directory and the client install option. (You could alternatively decide to run the WebSphere eXtreme Scale catalog and container servers in the WebSphere Commerce installation image by skipping step 1 and selecting the server installation option pointing to the WebSphere Commerce directory This is the approach taken in the Redbook referred to earlier).
- Augment all WebSphere Commerce nodes with WebSphere eXtreme Scale using the WebSphere Application Server profile management tool.
Create the eXtreme Scale grid configuration
The configuration in this example uses a standalone WebSphere eXtreme Scale deployment. You can optionally run the catalog servers in the deployment manager, node agents, or application servers of a WebSphere Application Server cell. By default, the WebSphere eXtreme Scale catalog server will run in the deployment manager of the cell when WebSphere eXtreme Scale is installed into a WebSphere Application Server environment. Additional care must be taken in the WebSphere Application Server configuration to manage the appropriate node agents and servers. For simplicity, the catalog and container servers described here run as standalone processes. This is generally a good configuration and provides a fair degree of isolation for independent management. However, it is not universally the right choice for every user. Careful consideration must be given to the creation and placement of catalog and container servers in a production environment. For example, you would certainly want more than the single catalog server defined for this simple scenario. In a production environment, multiple catalog servers within a catalog server domain should be defined for resiliency.
- Start the catalog server
Every grid environment must have a catalog server. In this simplified environment, a single catalog server will be started as a standalone process. For this example, start a catalog server with the following command from within the <WXS_HOME>/ObjectGrid/bin directory (if you are using a Windows server, use the *.bat scripts and appropriate path statements rather than the Linux example displayed here):
The <WXS_HOME> directory is the directory where WebSphere eXtreme Scale was installed. (See the Information Center for more information on starting a catalog service using the non-default catalog service endpoints or port.)
- Start the container servers
Once the catalog server is available, you can start the container servers to host the dynamic cache data in a WebSphere eXtreme Scale grid. For this example, start two standalone container servers. As with the catalog server, a production environment would be configured differently depending upon your particular needs. At a minimum, you should create at least three container servers for better distribution of the grid content.
WebSphere eXtreme Scale provides a set of files for the default configuration of the dynamic cache grid. You should copy these files to a new location, for example <CONFIG_HOME>, and edit them as necessary.
In a standalone installation the files can be found in either the <WXS_HOME>/ObjectGrid/dynacache/etc directory or in the <WAS_HOME>/optionalLibraries/ObjectGrid/dynacache/etc directory for a WebSphere Application Server deployment.
The configuration consists of two files that define both the structure of the grid and the deployment characteristics of the grid for dynacache:
- dynacache-remote-objectgrid.xml provides the definition of the grid that is required by the WebSphere eXtreme Scale dynamic cache provider. You should not need to edit this file.
- dynacache-remote-deployment.xml provides the deployment characteristics of the grid. You should become familiar with the contents of this file and edit as necessary. See the Information Center for a description of the file contents.
In this sample, make two minor changes to the dynacache-remote-deployment.xml:
- numInitialContainers=”2” changed from the initial value of “1.” This specifies that you will be running two containers and the data grid should not start until there are at least two container servers available. This will assure an even distribution of data for the partitions.
- developmentMode=”true” changed from the initial value of “false.” The sample environment is running all containers on the same node. Normally, replicas will only be created on different nodes from the primary. You must set this for development mode to indicate that you would like replicas created even though the container servers are on the same node.
When running standalone container servers, these files are provided as parameters to the startOgServer command along with parameters to locate the catalog service. Use the following commands to start each of the container servers from within the <WXS_HOME>/ObjectGrid/bin directory:
./startOgServer.sh container1 -objectGridFile <CONFIG_HOME>/dynacache-remote-objectgrid.xml -deploymentPolicyFile <CONFIG_HOME>/dynacache-remote-deployment.xml -catalogServiceEndPoints localhost:2809
./startOgServer.sh container2 -objectGridFile <CONFIG_HOME>/dynacache-remote-objectgrid.xml -deploymentPolicyFile <CONFIG_HOME>/dynacache-remote-deployment.xml -catalogServiceEndPoints localhost:2809
These updates create the environment depicted in Figure 16.
Figure 16. Sample grid layout
See the Information Center for more information on starting a container service using the non-default catalog service endpoints or port.
After completing these steps, you now have a configuration initialized to host the dynamic cache data grid.
Configure the WebSphere Commerce server
The next step is to configure the WebSphere Commerce application server to utilize the WebSphere eXtreme Scale dynamic cache provider that will connect to the catalog and container servers that you just defined. At a high level, this means you need to change the WebSphere Commerce Server dynamic cache provider to be WebSphere eXtreme Scale, add some custom properties for the WebSphere Commerce server JVM, and create the WebSphere eXtreme Scale client catalog service domain to point to your catalog service.
- Configure the dynamic cache provider
- Start by selecting the WebSphere Commerce server in the WebSphere
Integrated Solutions Console by selecting Servers > Server Types
WebSphere application servers and then selecting
server1. Expand Container Services under Container
Settings and click Dynamic cache service, as shown in Figure 17.
Figure 17. Container services
- Next, click on the Cache provider drop-down and select WebSphere eXtreme Scale (Figure 18).
Figure 18. Cache provider
- Verify that the Enable cache replication option is checked, as shown in Figure 19.
Figure 19. Enable cache replication
- Click OK and then save the changes to the master configuration (Figure 20).
Figure 20. Save changes
- Start by selecting the WebSphere Commerce server in the WebSphere Integrated Solutions Console by selecting Servers > Server Types > WebSphere application servers and then selecting server1. Expand Container Services under Container Settings and click Dynamic cache service, as shown in Figure 17.
- Add custom properties for WebSphere eXtreme Scale dynamic cache
Next, you will add some necessary custom properties to the JVM for the WebSphere Commerce server. You will add four property key/value pairs. Just an overview of the properties will be presented here; see the Information Center for details on the attributes and the meaning of each setting.
This is the most important property you need to set. Add it with a value of remote. This specifies the topology of the WebSphere eXtreme Scale dynamic cache that you are configuring for this server. You are using remote to signify that the cache data is stored outside of the WebSphere Commerce JVMs. Other potential values are local, embedded, and embedded_partitioned, depending upon the configuration desired.
This is a performance recommendation to prevent recursive invalidations of dependency IDs. Set this to true.
This is also a performance recommendation. Set the value to true to indicate that the cache value should not be de-serialized for a change event.
This is another performance recommendation to compress the content of the dynamic cache. Setting the value to true will reduce the size of the data in the cache and reduce network traffic.
You will make these changes once again using the WebSphere Integrated Solutions Console.
- Select Servers > Server Types > WebSphere application
servers from the navigation panel and then select server1 in the
panel to the right. Under Server Infrastructure, click
Java and Process Management > Process definition, as shown in Figure 21.
Figure 21. Java and Process Management
- In the Process definition panel, select Java Virtual Machine
under Additional Properties (Figure 22).
Figure 22. Java Virtual Machine
- Select Custom Properties under Additional Properties (Figure 23).
Figure 23. Custom properties
- You should now see the view of custom properties for this server, similar to that shown in Figure 24.
Figure 24. Properties
- For each property in Table 1, click on New (highlighted in
Figure 24), enter the Name and Value of the property,
and then click OK. You will notice a message to save the configuration. You can wait and do this just once after all of the properties have been added.
Table 1. Property names and values
Property name Value com.ibm.websphere.xs.dynacache.topology remote com.ibm.websphere.xs.dynacache.disable_recursive_invalidate true com.ibm.websphere.xs.dynacache.ignore_value_in_change_event true com.ibm.websphere.xs.dynacache.enable_compression true
- Save the new settings by clicking Save in Figure 25.
Figure 25. Save settings
- Your new list of properties should look similar to Figure 26. The new entries are highlighted in the figure.
Figure 26. Completed properties
- Create catalog server domain for WebSphere eXtreme Scale catalog servers
The next step is to configure the WebSphere eXtreme Scale catalog service domain to reference your catalog servers. Once again, start with the Integrated Solutions Console in WebSphere Application Server.
- In the navigation panel, expand System administration >
WebSphere eXtreme Scale. Click on Catalog service domains
and you will see the view shown in Figure 27. You need to create a
new catalog service domain so click on New.
Figure 27. Catalog service domains
- Enter the Name you would like to use to reference this domain
on the panel to create a new catalog service domain. The value
wxs71is used in this example. Because your catalog server is running outside of the WebSphere Application Server, select Remote Server, enter the Remote Server hostname for the catalog service, and enter the Listener Port of
2809(this is the default; your port might be different). Also, validate that this domain is set as the default by selecting the check box below the Name field, as shown in Figure 28. Click OK to create the new domain.
Figure 28. New catalog service domain
- You can either test the connection or save your changes to the master
configuration at this point. To save the changes first, click Save (Figure 29).
Figure 29. Save catalog service domain
- To validate your settings are correct, you can test the connection by
selecting the domain that you just created and click Test connection (Figure 30).
Figure 30. Test connection
If everything is working correctly, you should see the message displayed in Figure 31 near the top of the panel.
Figure 31. Connection successful
This concludes the steps for configuring WebSphere Commerce to use dynamic cache to leverage an external standalone WebSphere eXtreme Scale grid. Just one more administration step is necessary and you can test it out.
- In the navigation panel, expand System administration > WebSphere eXtreme Scale. Click on Catalog service domains and you will see the view shown in Figure 27. You need to create a new catalog service domain so click on New.
- Recycle the WebSphere Commerce server
You must recycle the WebSphere Commerce servers. Before we do this, however, it is helpful to ensure that you have the necessary catalog server and container servers running for WebSphere eXtreme Scale. These should be running from the steps you took earlier.
You can use whatever mechanism you prefer to restart the WebSphere Commerce Server. If you are running a single server environment, as in this example, restart the server via the command line:
Enter the administrator ID and password if prompted. Next, start the server again with this command:
When the server is active, all of the configuration changes will take effect and the server should connect to the data grid. If everything worked, you should see the messages displayed in Listing 1 in the SystemOut.log of your WebSphere Commerce server.
[3/2/11 9:45:05:503 EST] 00000000 CacheServiceI I DYNA1054I: Dynamic Cache (core cache) initialized successfully. [3/2/11 9:45:05:519 EST] 00000000 ObjectCacheSe I DYNA1056I: Dynamic Cache (object cache) initialized successfully. [3/2/11 9:45:05:531 EST] 00000000 CacheProvider I CWOBJ4500I: WebSphere eXtreme Scale Dynamic Cache provider is successfully initialized. [3/2/11 9:45:06:454 EST] 00000000 ObjectGridImp I CWOBJ4700I: The map name IBM_DC_PARTITIONED_baseCache matched the regular expression of template map IBM_DC_PARTITIONED_.*. The IBM_DC_PARTITIONED_baseCache map has been created for ObjectGrid DYNACACHE_REMOTE. [3/2/11 9:45:06:488 EST] 00000000 CacheProvider I CWOBJ4508I: The WebSphere eXtreme Scale provider has created a Dynamic Cache instance with name baseCache using topology remote.
Validate that WebSphere eXtreme Scale is being used for the dynamic cache
You can now validate that the configuration is working as intended. You can determine from the SystemOut.log whether things are configured properly and the WebSphere Commerce server is connected to the grid. However, it is always nice to see actual entries being added into the WebSphere eXtreme Scale grid to confirm that things are in fact working correctly.
Before you can see content in the data grid, you need to do something to actually generate some content. This example uses the Madisons store sample. (See step 11 in the Using the default dynamic cache provider section for information on using the sample to drive content into the dynamic cache.) After the configuration steps and restarting the server, a portion of that content will now be stored in the data grid. You then must interact with the sample to get some content added to the dynamic cache and, therefore, added to the data grid.
Validation using xsadmin
Perhaps one of the easiest ways to get an idea of the content of the entries in the grid is using the xsadmin.sh or xsadmin.bat scripts provided with WebSphere eXtreme Scale. You can find these scripts in <WXS_HOME>/ObjectGrid/bin.
For example, you can view the sizes of the partitions in the grid using this command:
In this configuration, this command yielded the following results (with some partition
details removed to save space). (You must have performed some action to add content
to the grid before you will see any output from the
xsadmin.sh -mapsizes command. If you do not see similar output then you may have to revisit some of the configuration steps.)
/IBM/WebSphere/eXtremeScale/ObjectGrid/bin> ./xsadmin.sh -mapsizes This Administrative Utility is provided as a sample only and is not to be considered a fully supported component of the WebSphere eXtreme Scale product Connecting to Catalog service at localhost:1099 ****Displaying Results for Grid - DYNACACHE_REMOTE, MapSet - DYNACACHE_REMOTE****** *** Listing Maps for container1 *** Map Name Partition Map Size Used Bytes (KB) Shard Type IBM_DC_PARTITIONED_baseCache 0 2 656 AsynchronousReplica IBM_DC_PARTITIONED_baseCache 1 2 656 Primary IBM_DC_PARTITIONED_baseCache 2 2 656 Primary IBM_DC_PARTITIONED_baseCache 3 3 2 AsynchronousReplica IBM_DC_PARTITIONED_baseCache 4 2 656 AsynchronousReplica IBM_DC_PARTITIONED_baseCache 5 3 2 Primary IBM_DC_PARTITIONED_baseCache 6 2 656 Primary ... IBM_DC_PARTITIONED_baseCache 41 3 3 AsynchronousReplica IBM_DC_PARTITIONED_baseCache 42 2 656 Primary IBM_DC_PARTITIONED_baseCache 43 2 656 Primary IBM_DC_PARTITIONED_baseCache 44 2 656 AsynchronousReplica IBM_DC_PARTITIONED_baseCache 45 2 656 Primary IBM_DC_PARTITIONED_baseCache 46 3 2 AsynchronousReplica Server Total: 105 (57KB) *** Listing Maps for container2 *** Map Name Partition Map Size Used Bytes (KB) Shard Type IBM_DC_PARTITIONED_baseCache 0 2 656 Primary IBM_DC_PARTITIONED_baseCache 1 2 656 AsynchronousReplica IBM_DC_PARTITIONED_baseCache 2 2 656 AsynchronousReplica IBM_DC_PARTITIONED_baseCache 3 3 2 Primary IBM_DC_PARTITIONED_baseCache 4 2 656 Primary IBM_DC_PARTITIONED_baseCache 5 3 2 AsynchronousReplica IBM_DC_PARTITIONED_baseCache 6 2 656 AsynchronousReplica ... IBM_DC_PARTITIONED_baseCache 41 3 3 Primary IBM_DC_PARTITIONED_baseCache 42 2 656 AsynchronousReplica IBM_DC_PARTITIONED_baseCache 43 2 656 AsynchronousReplica IBM_DC_PARTITIONED_baseCache 44 2 656 Primary IBM_DC_PARTITIONED_baseCache 45 2 656 AsynchronousReplica IBM_DC_PARTITIONED_baseCache 46 3 2 Primary Server Total: 105 (57KB) Total Domain Count: 210 (114KB) (The used bytes statistics are accurate only when you are using simple objects or the COPY_TO_BYTES copy mode.)
There are several things to note in the output above:
- You can see that the name of the grid and MapSet are both DYNACACHE_REMOTE. These are the default grid and MapSet names used by the WebSphere eXtreme Scale dynamic cache provider.
- The map name is IBM_DC_PARTITIONED_baseCache. This is the default map that is used for the base cache dynamic cache implementation.
- Both container servers are listed with an appropriate distribution of primary and asynchronous replicas.
- Partitions with map sizes greater than 2 contain dynamic cache specific content. Every partition will automatically include two entries used for management purposes as part of the dynamic cache implementation. Any additional entries represent application content in the dynamic cache.
- The xsadmin utility in WebSphere eXtreme Scale V7.1 (used in the sample) should consistently present entries in either bytes or kilobytes (KB). However, until all entries grow to a size greater than 1KB there is a mixture of byte and KB entries in the table. In the output above, the entries with a bytes used count of 656 represent 656 bytes while those with bytes used count of 2 or 3 represent kilobytes used. (As noted in the banner of the output, xsadmin is an unsupported utility, but hopefully there will be an iFix available soon to correct this issue.)
- The total server size is presented for each container server. This size is correctly calculated and displayed in KB.
Validation using the WebSphere eXtreme Scale web console
The recommended way to validate the dynamic cache content in the WebSphere eXtreme Scale data grid is to use the new WebSphere eXtreme Scale web console, available in V7.1. The console enables you to chart current and historical statistics for the grids in your environment. (See this video on how to configure and use the WebSphere eXtreme Scale web console for monitoring your grids.)
The WebSphere eXtreme Scale web console provides a number of nice features for viewing the content of and using a data grid. A few examples of these will be shown here and you can explore others on your own.
Access the web console from a browser using https://<hostname>:7443/ . The
default userid ID and password are both
admin until you change them. Follow the steps in the video and product documentation to create a domain.
After you have the console configured, click on the Monitor drop-down and then on Data Grid Domain Overview to see the view shown in Figure 32. As with the xsadmin.sh command, you can see the data grid listed for DYNACACHE_REMOTE once again in this view. You can also see that your data grid has received some content given the usage in this view. You have only used a small portion of your grid at the moment, but there are some entries in the grid to look at.
Figure 32. Data grid domain overview
Now, click on Data Grid Overview, also under Monitor, to see items such as used capacity, cache usage, response time, and throughput summaries, as shown in Figure 33.
Figure 33. Individual data grid overview
You can view the details for the data grid by selecting Data Grid Details from under Monitor and then clicking on the map used for the dynamic cache implementation, IBM_DC_PARTITIONED_basecache, as shown in Figure 34.
Figure 34. Data Grid Detail Reports
Finally, click on Server Overview, once again under Monitor. This will display memory usage statistics for the current usage, as well as minimums and maximums over time (Figure 35).
Figure 35. Server overview
There are many helpful statistics available in the WebSphere eXtreme Scale web console and additional exploration and creation of custom views is recommended.
This article described how you can implement a scenario that leverages a standalone WebSphere eXtreme Scale installation to provide the dynamic cache for a WebSphere Commerce image. You learned about the performance and scale benefits of this configuration with step-by-step directions on how to configure a simple grid for this purpose, and how to configure the WebSphere Commerce server to access that grid. Pointers to a number of utilities and monitoring tools that can be used to view the contents of the data grid and manage the dynamic cache were also provided in this article.
Special thanks to Jim Krueger, Charles Le Vay, and Lan Vuong, all from IBM US, and Aaron Leung, from IBM Canada, for their contributions to this article.
- WebSphere eXtreme Scale product information
- WebSphere Commerce product information
- WebSphere Commerce data cache
- Dynamic cache provider
- Redbook: Scalable, integrated solutions for elastic caching using WebSphere eXtreme Scale, SG24-7926
- Enhancing WebSphere Commerce performance with WebSphere eXtreme Scale
- Dynamic cache service settings
- Monitoring with the web console
- Video: WebSphere eXtreme Scale Monitor video
- IBM developerWorks WebSphere
Get products and technologies
- Extreme Transaction Processing (XTP) wiki
- WebSphere eXtreme Scale and DataPower XC10 Appliance product wiki