Tips and techniques for WebSphere eXtreme Scale DynaCache in WebSphere Commerce environments, Part 1: General caching and WebSphere eXtreme Scale servers

This series focuses on the best practices for the integration of IBM® WebSphere® eXtreme Scale DynaCache in WebSphere Commerce Server environments. WebSphere eXtreme Scale is a distributed caching solution that is a popular provider of DynaCache in large WebSphere Commerce Server environments. WebSphere Commerce Server customers have successfully integrated WebSphere eXtreme Scale DynaCache in large and small production environments. While the configuration of WebSphere eXtreme Scale DynaCache in a WebSphere Commerce Server environment is simple, you need to pay special attention to the best practices for design, usage, operational patterns, and tuning.

Ravi Tripathi (ravi.tripathi@us.ibm.com), Managing Consultant, IBM

Ravi Tripathi is an IBM Managing Consultant working on the Smarter Commerce platform in IBM Software Services for Industry Solutions (ISS-IS). In this role, Ravi advises large retail corporations about Smarter Commerce implementation architecture, design, infrastructure, performance, and launch. He is an expert in designing and developing omni-channel, high-performing Smarter Commerce solutions for large retailers in North America. Ravi received his Master's degree in Production Engineering.



Dr. Debasish Banerjee (debasish@us.ibm.com), WebSphere Consultant, IBM

Photo of Dr. Debasish BanerjeeDr. Debasish Banerjee is presently a WebSphere consultant in IBM Software Services. He started his WebSphere career as the WebSphere internationalization architect. Extreme transaction processing, distributed cache, elastic computing, and cloud computing are his current areas of interest. Debasish received his Ph. D. in the field of combinator-based Functional Programming languages.



Anupam Basu (anupam@us.ibm.com), IT Architect, IBM

Anupam Basu is an certified IT architect with IBM Software Group and helps customers implement e-commerce solutions with IBM Smarter Commerce and the IBM Middleware portfolio of products. He has extensive experience in designing and developing enterprise architectures. He helped build several high-volume and high-performing Smarter Commerce solutions for large retailers in North America. He earned double Master's degree in Statistics and Computer Science from Indian Statistical Institute, Calcutta, India.



Jim Krueger (jim_krueger@us.ibm.com), Advisory Software Engineer, IBM

Jim Krueger is an IBM Advisory Software Engineer working on the WebSphere eXtreme Scale development team. He is the lead WebSphere eXtreme Scale Dynamic Cache developer. In this role, he frequently advises large corporations about WebSphere eXtreme Scale technology. Before joining WebSphere eXtreme Scale, Jim was a member of the WebSphere Application Server EJBContainer development team.



10 January 2013

Also available in Chinese Portuguese

Introduction

This three-part best practices series focuses on the tips and techniques involved in integrating WebSphere eXtreme Scale DynaCache into WebSphere Commerce Server environments. The tips and techniques in this series are based on successful launch experiences with some of the largest WebSphere Commerce Server installations. The series includes information about designing, deploying, configuring, and tuning applications in WebSphere Commerce environments.

The series does not provide step-by-step instructions for installation and configuration of the WebSphere eXtreme Scale DynaCache in WebSphere Commerce Server environments. Basic WebSphere eXtreme Scale DynaCache setup information is found in Bohn's article "Configure WebSphere Commerce to use WebSphere eXtreme Scale for dynamic cache to improve performance and scale" and also in the "Configuring the dynamic cache provider for WebSphere eXtreme Scale" topic in the WebSphere eXtreme Scale information center, see Resources.

WebSphere Commerce Server

The WebSphere Commerce Server is an IBM e-commerce framework that is widely used in retail environments of many sizes. The WebSphere Commerce Server contains the components for the various B2B and B2C functionalities needed in a retail environment.

WebSphere Commerce Server applications use databases for their operations and to speed up the operations of the applications. The applications also use Dynamic Cache (DynaCache) APIs from IBM WebSphere Network Deployment. DynaCache APIs from IBM cache are used to construct objects. Until WebSphere Commerce V6.1.0.39, WebSphere Application Server Network Deployment only provided an implementation of DynaCache APIs known as traditional DynaCache. A traditional DynaCache implementation caches portions of the data that are used in the available heap space of the WebSphere Commerce Server Java™ virtual machines (JVMs). The JVMs also store the rest of the overflow disks that are provided as expensive Storage Access Network (SAN) volumes.

With WebSphere eXtreme Scale, there is now an alternative implementation of the DynaCache APIs that is coherent, elastic, and does not use disks. When compared to traditional DynaCache, the WebSphere eXtreme Scale DynaCache implementation has the potential to provide:

  • Up to a 25% reduction in average response time
  • Up to a 40% improvement in time to reach steady state after full or partial site restart or after full cache invalidation

Potential benefits of WebSphere eXtreme Scale DynaCache include:

  • Consistent response time
  • Fast WebSphere Commerce recovery time
  • Organic cache warm-up
  • Simpler administration
  • Simpler tuning

WebSphere eXtreme Scale DynaCache is a coherent global cache with only one source of data that eliminates any possibility of serving stale data. The global WebSphere eXtreme Scale DynaCache also eliminates the cold cache hits on the back-end. Benchmark results with earlier versions of WebSphere eXtreme Scale DynaCache are discussed in the "Enhancing WebSphere Commerce performance with WebSphere eXtreme Scale" article.


General caching

It is important that you understand the typical cacheable entities that are involved in a WebSphere Commerce-based multi-channel e-commerce solution. This understanding allows you to create an effective caching strategy between WebSphere Commerce and WebSphere eXtreme Scale. This understanding is also important when considering how the cacheable entities are identified and their lifecycle is defined including the eviction strategy.

A typical WebSphere Commerce Server-based solution has cacheable entities that can be classified as:

  • WebSphere Commerce data cache (object cache) - Includes the Java™ objects that have database data encapsulated.
  • Command cache - Includes the Java objects that are executed as part of satisfying an inbound request. These typically enforce system-specific business logic or perform atomic transaction. There is some overlap between this cache type and data cache.
  • HTTP response cache (JavaServer pages (JSP) or View Cache) - Includes the Java object that typically represents the http response generated corresponding to an inbound http request. This response is displayed on the web site.

Figure 1 illustrates the relative position of each of the cache categories in the overall WebSphere Commerce solution programming framework.

Figure 1. Cache categories
Illustration of the cache-categories

For a better understanding of the commerce solution components, refer to the "WebSphere Commerce common Architecture" topic in the WebSphere Commerce information center documentation, see Resources.

Figure 1 illustrates how the HTTP response cache corresponds to Java objects that are generated in the presentation layer of the solution. It also illustrates how the command cache corresponds to the Java objects generated in the business logic layer. And how the WebSphere Commerce data cache corresponds to Java object representation of the data in the persistence layer of the solution.

This cache can be stored in the default traditional DynaCache provider for the WebSphere Application Server provider or the WebSphere eXtreme Scale DynaCache provider. The traditional DynaCache provider for the WebSphere Application Server provides an in-memory cache with the ability to offload the cache to disk. There are two key drawbacks when you use this cache provider:

  • Cache entities are localized to each server of the application cluster.
  • Cache invalidation must be done on each server of the application cluster.

These drawbacks result in the lifecycle of the cache entity (creation, management, and eviction) being repeated for each server in the application cluster.

Both of these drawbacks are addressed when you use the WebSphere eXtreme Scale DynaCache provider in a solution. The result is only one lifecycle (creation, management, and eviction) for each cacheable entity in the overall solution. This reduces cache eviction challenges and priming of cache for the application.

Best practices for caching design and decisions

An important decision in the caching design is to determine which cache type would be the best fit for each of the eligible caching scenarios in the application.

The key points to consider when selecting an appropriate cache type for a scenario are:

  • The frequency of access to a data or function by the application. Consider caching data or an application logic operation if it is accessed frequently by the application and it remains fairly constant or has limited variation for user groups over a significant period of time.
  • The cost to access the data and perform the application logic operation with every transaction, and the size of the cached entity. The use of command cache is typically more beneficial than a JSP or View cache. Most of the operations that take a lot of system resources and time (like external system integration, database operations, and business computations) are done in the business-logic tier (commands). Therefore, it is effective to include command cache in the overall solution design. In a typical implementation, full-page or fragment cache-entry (HTTP response cache) is typically larger than the corresponding business-logic-tier command cache-entities. If you choose the HTTP-response cache type, the full-page cache option may be preferred over the fragment cache.

    NOTE: Full-page cache is preferred because aggregating many fragment caches has performance costs and implications.

  • The frequency of invalidation of the cached entity by the application. A cached entity that is invalidated frequently based on user action or system changes is critically evaluated for the cache-worthiness. If the entity is cache-worthy, the traditional DynaCache provider is the best choice. This is because you must avoid the use of the WebSphere eXtreme Scale cache provider for the cacheable entities that require frequent invalidation.
  • The personalization characteristic of the cached entity in the application. For personalized customer data or operations, command cache is preferred to full page cache. An example is a personalized product recommendation or marketing content recommendation that is displayed on the web site. The personalization could be based on a customer's registration state (registered or anonymous), member group affiliations, or various other parameters. To effectively implement the caching of an entity that contains personalized data, you use the user identifier or member group association that is based on the request attributes (example: a cookie) to identify the user state or the member group affiliation and use it to create a cache ID for the cached-entity. For a relatively static data or response, you can use JSP cache. A good example of this situation is the Contact Us or Help pages. These are pages where the information is not personalized or dynamic in nature.

Table 1 provides the cache types and their typical preference rank (1 highest to 4 lowest) based on our field experience.

Table 1. Cache types and preference ranking (highest to lowest)
PreferenceCache type
1 WebSphere Commerce data cache
2 Command cache
3 HTTP response cache (full page cache)
4 HTTP response cache (fragment cache)

The caching design and the application design must be complementary. Instead of using the data bean directly with JSPs, you can use a pattern in the Business logic tiers (commands) to create an aggregate value object or value object that is then passed to JSP or View Cache to create the response. This helps in the caching of business logic commands that are invoked frequently by the application.


WebSphere Commerce data cache (object cache) overview and implementation specifics

The WebSphere Commerce programming framework allows you to perform more caching of database query results. This additional caching code is referred to as the WebSphere Commerce data cache, and it uses the functionality that is provided by WebSphere dynamic cache service. This functionality reduces the database trips and improves the system throughput and response time and is available in WebSphere Commerce V7.0 or later.

NOTE: This programming framework is not enabled by default. You need to perform specific actions to enable it for WebSphere Commerce Server feature pack 4 and earlier.

WebSphere Commerce data cache is classified in two types that are based on tenure of cache and its usage or applicability across multiple user requests.

  • Cross transaction cache (recommended) - Cache that persists across multiple transactions (corresponding to different user requests). This cache offers the most benefit due to long life of the cache and reusability across multiple transactions. Cross transaction cache is the recommended cache pattern.
  • Local transaction cache - Cache that persists only until the transaction boundary associated with a specific user's request. This cache pattern is for objects that use database information multiple times during a single transaction scope.

WebSphere Commerce data cache is implemented with either of two approaches:

  • Command caching - Caching approach that uses the cachespec.xml (dynamic Cache service cache configuration file) for the cache entry specification. If cachespec.xml is used for defining data cache, then cache entries, by default, go to Base Cache instance. This caching approach is usually not the best choice for the implementation of data caching.
  • Distributed map caching approach (recommended) - Caching approach that configures the object-cache instances using the information that is provided in the "Using the Distributed and DistributedObjectCache interfaces for the dynamic cache" topic on the WebSphere Application Server information center, see Resources.

You define the object-cache instances in the WebSphere Application Server. You can define the object-cache instances either with the integrated administration console or with scripting. Remember that not all the object-cache instances are configured to use the WebSphere eXtreme Scale provider. However, object-cache instances that are configured to use WebSphere eXtreme Scale as the cache provider need the appropriate custom properties that are defined for the object-cache instance. For more information about data cache, refer to the "Enabling WebSphere Commerce data cache" topic in the WebSphere Commerce information center, see Resources.

Define the cache entry to object-cache-instance mapping. Defining the cache entry is done with the WebSphere Commerce configuration XML file named wc-server.xml. The data cache is configured based on the scope of the cache entry using the CrossTransactionCache or LocalTransactionCache tag within the InstanceProperties element of the WebSphere Commerce configuration file. This configuration is for long-lived cache entries. If you use the wc-server.xml file, the entries go to the dynamic maps (DMAP) that are configured in WebSphere eXtreme Scale. For the details on this configuration, refer to the "Additional WebSphere Commerce data cache configuration" topic on the WebSphere Commerce information center, see Resources.

Best practices for WebSphere Commerce data cache implementation

Configure the DMAPs to exist in WebSphere eXtreme Scale cache provider for the data cache entities that are used frequently across multiple user transactions and not invalidated frequently. Cached entities that are invalidated, either programmatically or using the DynaCacheInvalidationCmd, should be configured to use the traditional DynaCache provider. It is important for you to remember that the WebSphere Commerce data-cache components do not only fetch the entities from WebSphere eXtreme Scale. They also cause the programmatic cache entry invalidation calls to reach WebSphere eXtreme Scale. Frequent invalidation messages are not cheap and idempotent. They can cause an increase in CPU utilization on WebSphere eXtreme Scale servers. For this reason, invalidation frequency and count is an important design and implementation consideration. For example, business context service (BCS)-related cache, that is implemented using the class com.ibm.commerce.component.contextservice.commands.ContextDataSerValueCache CmdImpl, is frequently invalidated based upon the user's action on the web site. So, it is recommended that you do not offload this cache entry to WebSphere eXtreme Scale.

Table 2 provides the recommended destination for the DMAPs that are available with WebSphere Commerce data cache. This table is not a comprehensive list, but the table is accurate as of WebSphere Commerce V7.0 FEP 4.

Table 2. Recommended destination of the DMAPs
DMAP Name Preferred Destination Comments
WCSystemDistributedMapCache WebSphere eXtreme Scale You determine the appropriate cache size that is based on your commerce foundational data setup, such as the supported languages, currency, country, states, shipping, and fulfillment data.

Initially, you keep the cache count size at 20000. You then optimize it based on the cache hit-or-miss ratio and the least recently used (LRU) evictions.
WCSessionDistributedMapCache
Traditional DynaCache The DMAP holds the commerce business context service (BCS) related data.

Initially, you can keep the cache count size at 5000. You then optimize it based on the cache hit-or-miss ratio and LRU evictions.
WCContractDistributedMapCache WebSphere eXtreme Scale Initially, you can keep the cache count size at 5000. You then optimize it based on the cache hit-or-miss ratio and LRU evictions.
WCPromotionDistributedMapCache
WebSphere eXtreme Scale This DMAP holds the commerce promotion engine-related runtime data. The DMAP size is determined by looking at the types of promotions that are configured, the number of promotions that are configured, and the creation of a shopping cart by the guest on the web site.

Initially, you can keep the cache count size at 30000. You then optimize the cache count that is based on the cache hit-or-miss ratio and LRU evictions.
WCMarketingDistributedMapCache
WebSphere eXtreme Scale Initially, you can keep the cache count size at 3000. You then optimize the cache count that is based on the cache hit-or-miss ratio and LRU evictions.
WCUserDistributedMapCache

Traditional DynaCache
Initially, you can keep the cache count size at 3000. You then optimize the cache count that is based on the cache hit-or-miss ration and LRU evictions.

You can start with Traditional DynaCache. However, you must also test with WebSphere eXtreme Scale as the destination. If the invalidation cost is NOT high in WebSphere eXtreme Scale, then you can use WebSphere eXtreme Scale as the destination.
WCCatalogGroupDistributedMapCache
WebSphere eXtreme Scale You determine the appropriate cache size that is based on your catalog structure and setup.

Initially, you can keep the cache count size at 20000. You then optimize the cache size that is based on the cache hit-or-miss ratio and LRU evictions.
WCCatalogEntryDistributedMapCache
WebSphere eXtreme Scale You determine the appropriate cache size that is based on your catalog structure and setup.

Initially, you can keep the cache count size at 20000. You then optimize the cache size that is based on the cache hit-or-miss ratio and LRU evictions.
WCPriceDistributedMapCache
WebSphere eXtreme Scale You determine the appropriate cache size that is based on your price rule and offer setup.

Initially, you can keep the cache count size at 20000. You then optimize the cache count that is based on cache hit-or-miss ratio and LRU evictions.
WCDistributedbutedMapCache
WebSphere eXtreme Scale Initially, you can keep the cache count size at 1000. You then optimize it based on the cache hit-or-miss ratio and LRU evictions.

WebSphere eXtreme Scale servers

The WebSphere eXtreme Scale grid contains two types of WebSphere eXtreme Scale servers:

  • Catalog server - Provides management of the entire grid.
  • Container server - Contains all the cached data.

Catalog servers play an important role during grid recoveries that start or stop container servers. For example, catalog servers play this role during communication failures, hardware failures, and when clients connect to the grid for the first time. However, catalog servers do not play much of a role when already connected clients are accessing a grid in steady state.

In a typical grid, data is partitioned into a number of container servers. A WebSphere eXtreme Scale grid must be designed to avoid the loss of a subset of container servers during run time. For high availability, catalog servers are clustered. This ensures that data is not lost if the catalog service becomes unavailable and the entire grid of both the catalog and container servers must be restarted. You also need at least two catalog servers in any catalog-server cluster.

WebSphere eXtreme Scale grids can be updated with newer versions of the WebSphere eXtreme Scale software without a complete grid restart that results in data loss. For a WebSphere eXtreme Scale software upgrade, depending on the version of the WebSphere eXtreme Scale software, catalog servers are upgraded before the container servers. For ease of upgrade and general grid maintenance, catalog and container servers are hosted in separate machines. If it is not possible to have separate machines, you can have separate installations for the catalog and the container servers.

For details on WebSphere eXtreme Scale servers, refer to the "Caching architecture: Maps, containers, clients, and catalogs" topic on the WebSphere eXtreme Scale information center, see Resources.

Best practices for forming a catalog server cluster

  • For high availability, a catalog-server cluster consists of at least two, preferably three, catalog servers. Also, no two cluster members can reside in the same physical machine or LPAR. A three-member catalog-server cluster ensures that if one catalog server machine goes down for maintenance, there are still two active catalog servers to avoid a Single Point of Failure (SPOF).
    NOTE: For efficient intracatalog server-cluster member communication, you cannot have more than four catalog servers in any catalog-server cluster.
  • All the catalog-server cluster-members must belong to the same core group. This restriction is automatically enforced in catalog servers that are created in stand-alone environments. You can also configure catalog servers in large WebSphere Application Server environments to satisfy this restriction.
  • All the catalog-server cluster-members are in the same subnet. This provides reliable intracatalog server communication that simplifies grid administration and configuration by preventing a potential grid condition called islanding. Islanding occurs when the WebSphere eXtreme Scale grid is partitioned into multiple independent grids.

WebSphere eXtreme Scale DynaCache topologies

The WebSphere eXtreme Scale DynaCache client is embedded in the WebSphere Application Server JVMs. You install the WebSphere eXtreme Scale client on the WebSphere Application Server installations on all the machines. The client (and the complete WebSphere eXtreme Scale server) installation contains the DynaCache plug-in code that is used by the WebSphere Commerce Server code to interact with the WebSphere eXtreme Scale DynaCache grid.

The WebSphere eXtreme Scale server code provides the implementation of DynaCache grid. The WebSphere eXtreme Scale DynaCache grid is typically configured in one of two topologies:

  • Embedded partitioned - Where cached data is partitioned in the WebSphere Commerce Server JVM. Embedded partitioning provides coherent caching service. However, it is of limited value in WebSphere Commerce Server environments.
  • Remote partitioned - Where WebSphere eXtreme Scale DynaCache is on a separate tier and not on the WebSphere Commerce Server JVMs. Remote partitioning provides a coherent cache with excellent isolation from client. This is the most widely used topology for WebSphere eXtreme Scale DynaCache in WebSphere Commerce Server environments.

The remote WebSphere eXtreme Scale DynaCache grid can be hosted on stand-alone JVMs or on WebSphere Application Servers. Both are viable deployment topologies and are used successfully in large production environments.


WebSphere eXtreme Scale DynaCache in WebSphere Application Server

WebSphere eXtreme Scale is tightly integrated with the WebSphere Application Server. The hosting of the WebSphere eXtreme Scale server on the WebSphere Application Server JVMs allows the use of the built-in features of the WebSphere Application Server to monitor, administer, test, and debug WebSphere eXtreme Scale. For example, the Performance Monitoring Infrastructure (PMI) of the WebSphere Application Server, the admin console, the logging, and the tracing facility can be used in WebSphere eXtreme Scale servers that are hosted in WebSphere Application Server Network Deployment environments. The WebSphere eXtreme Scale grids that are hosted in WebSphere Application Server Network Deployment environments can also be stopped without bringing down the corresponding WebSphere Application Server JVMs. It is also convenient to host and administer multiple WebSphere eXtreme Scale grids on the same WebSphere Application Server cluster.

WebSphere Application Server Network Deployment run time uses memory of about 100 MB in 32-bit architectures and 200 MB in 64-bit architectures for its operation. WebSphere eXtreme Scale container servers that are hosted on a WebSphere Application Server have memory available for caching data. However, the WebSphere eXtreme Scale containers of similar heap size on stand-alone JVMs do not. If you have many WebSphere eXtreme Scale servers in the DynaCache grid, you must explicitly administer core groups when these WebSphere eXtreme Scale servers are hosted on the WebSphere Application Server environments. For more information on WebSphere eXtreme Scale, refer to the "Super cluster to the rescue, Part 2: Maximum scalability using WebSphere DMZ Secure Proxy Server, ORD, and WebSphere eXtreme Scale" article. The use of the WebSphere Application Server to host WebSphere eXtreme Scale grid also involves more licensing costs. However, if you are familiar with the administration of the WebSphere Application Server, you can host the WebSphere eXtreme Scale server on your existing middleware to reduce your learning curve and increase productivity.


DynaCache in stand-alone JVMs

Because there is no WebSphere Application Server run time in stand-alone JVMs, there is more memory available for caching objects than there is in WebSphere Application Server JVMs of identical heap size. However, there is not a significant difference in speed when performing cache operations between stand-alone or WebSphere Application Server environments to host a WebSphere eXtreme Scale DynaCache grid. The DynaCache grid can be administered with the WebSphere eXtreme Scale xsadmin or xscmd command-line tools, see Resources.

To start DynaCache grids, you can use simple shell scripts. In stand-alone environments, even for large grids with many container servers, you do not have to worry about core-group configuration. WebSphere eXtreme Scale software automatically creates core groups of appropriate sizes. In stand-alone environments, you also do not have WebSphere Application Server licensing costs.

Best practices for WebSphere eXtreme Scale DynaCache grid topology

The remote topology is the recommended topology. In this topology, the WebSphere Commerce application uses the WebSphere eXtreme Scale DynaCache client to access the remote cache. To host the WebSphere eXtreme Scale DynaCache in the WebSphere Application Server environments, you must:

  • Pay for the extra licensing cost of WebSphere application server network deployment.
  • Have the memory that is needed for WebSphere application server run time.
  • Be familiar with the administration of the WebSphere application server network deployment.

If you do not want to host the WebSphere eXtreme Scale DynaCache in the WebSphere Application Server environments, then consider hosting the WebSphere eXtreme Scale DynaCache grid on stand-alone JVMs. The use of stand-alone JVMs as WebSphere eXtreme Scale servers is more popular in WebSphere Commerce Server environments. This series focuses on the remote WebSphere eXtreme Scale DynaCache topology hosted on stand-alone JVMs and all the relevant tips and techniques. The series also points out the strategic differences that are involved if you choose to deploy the WebSphere eXtreme Scale DynaCache grid in an WebSphere Application Server network deployment.


Conclusion

This three-part series focuses on WebSphere Commerce environments. However, most of the techniques are also applicable to general WebSphere eXtreme Scale DynaCache usage in any pure WebSphere Application Server network deployment or in WebSphere portal server environments. You can apply the tips and techniques in this series in your WebSphere Commerce implementation of the WebSphere eXtreme Scale DynaCache environment.

WebSphere eXtreme Scale is a rapidly evolving technology. There is an increasing investment in consumability, performance, monitoring capability, and domain of applicability of WebSphere eXtreme Scale and WebSphere eXtreme Scale DynaCache. As additional tips and techniques emerge and more utilities for monitoring are developed, the authors will provide updates to the WebSphere eXtreme Scale DynaCache series.


Acknowledgments

The authors are grateful to the following people for technical discussions regarding their work with WebSphere Commerce and WebSphere eXtreme Scale: Kyle Brown, IBM DE, ISSW; Brian Martin, STSM, WebSphere eXtreme Scale and XC10 Lead Architect; Douglas Berg, WebSphere eXtreme Scale Architect; Chris Johnson, WebSphere eXtreme Scale Architect; Jared Anderson, WebSphere eXtreme Scale Architect; Rohit Kelapure, WebSphere Application Server Development; Joseph Mayo, XC10 Development; Surya Duggirala, WebSphere Application Server Performance Lead; Matt Kilner, JDK L3; Brian Thomson, STSM, WebSphere Commerce Server CTO; Misha Genkin, WebSphere Commerce Server Performance Architect; Robert Dunn, WebSphere Commerce Server Development; Kevin Yu,ISS-IS. The authors would also like to acknowledge Mary A. Brooks for her superb copy editing. And a very special thanks to Cheenar Banerjee for her assistance in proofreading and suggesting several readability improvements.

Resources

Learn

Get products and technologies

Discuss

  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

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 Commerce on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Commerce, WebSphere
ArticleID=854365
ArticleTitle=Tips and techniques for WebSphere eXtreme Scale DynaCache in WebSphere Commerce environments, Part 1: General caching and WebSphere eXtreme Scale servers
publish-date=01102013