Home


WebSphere Commerce and WebSphere XD

We have already discussed the problem of managing large caches in WebSphere Commerce. We recommended extensive use of disk caching to reduce the size of the in-memory cache and reduce its impact on the Java heap. Clustering in a WebSphere ND environment gave us no solution to this problem because in an WebSphere ND clustered environment each server has the same elements in its cache as the other servers, and the same elements in its memory cache.

Would it be possible to partition the cache differently for each server and then route requests to the server which is most likely to have a requested element in memory? This is just what WebSphere XD can do for your WebSphere Commerce Web site.

Figure | -2 illustrates a catalog that contains 50,000 products. Each node has enough memory to hold at most 20,000 pages at any given time. Suppose the next request is for the product with the id 20001. This will result in a cache miss, and since the cache of each node is full, an entry will be expelled or offloaded to disk to make room for the requested page.

Figure B-2 Traditional Commerce topology with a large catalog

In a WebSphere XD environment it is possible for all of the catalog pages to be in-memory at one time. Create partitions in your cluster using WebSphere Partitioning Facility (WPF) and divide the catalog among the nodes, or groups of nodes. The partition could be defined using the product identifier (for example, products 1-15000 are assigned to partition 1, products 15000-30000 are assigned to partition 2, and so forth). A node (or node group) is then responsible for a subset of the catalog and it could be contained entirely in memory. Figure | -3 illustrates the partitioned XD environment.

Note: To achieve maximum performance benefits, each partition must be carefully defined to be no larger than the memory you have decided to allocate from the JVM heap on each node. If the number of catalog pages each partition is responsible for is at most the size of the in-memory cache, then disk caching is avoided altogether. Avoiding disk cache is not always achievable and is not necessary to get reasonable performance.

Figure B-3 Partitioned WebSphere Commerce topology

What happens when a request is received from a Web client? The request is received by the ODR. The ODR uses the expression defined in partitions.xml to identify the product ID in the incoming HTTP request and map the request to a partition. The request is then sent to a node in the partition. If the page has been accessed before, and not invalidated, the node will have the catalog page in memory. When looking at what partitions to create you should start with separating browsing traffic from buying traffic. Once you have achieved this level of partitioning you can then determine if more partitioning is required.

+

Search Tips   |   Advanced Search