6.2.2 What to expect when using WebSphere eXtreme Scale
The integration between WebSphere Commerce and WebSphere eXtreme Scale does not require any change to applications using the dynamic cache API. But there are small changes to the behavior and the way the cache is managed. The differences in the architecture are illustrated in Figure 6-2 and Figure 6-3 and provide the background for comparing the difference.
Figure 6-2 shows a typical deployment of the default dynamic cache provider. You can see that each application server contains the same cached data. This is replicated between the application servers on a best-efforts basis. In reality, the dynamic cache service provides a variety of replication options. First, it can copy all data to every server, so all servers contain the same data. But that is expensive to do. Alternatively, it can just publish invalidation events to every server, so that servers will not retain stale data. This is more efficient replication but means each server has to create their own cache entry. Regardless of the sharing mode, as the site reaches a steady state, each Commerce server will contain the same cached data. Also, every server will only contain a subset of the whole cache, with every server maintaining a disk off load of the cache. This is slower than an in-memory cache, but quicker than having to recreate the cache entry every time. However, for a large environment, that can be a significant disk requirement.
Figure 6-2 Example dynamic cache environment
Figure 6-3 shows a remote topology deployment of the WebSphere eXtreme Scale dynamic cache provider. You can see that all data is placed in WebSphere eXtreme Scale and that the Commerce application servers have no responsibility for cache management. There is no cache replication traffic or disk off load. In contrast, all cache accesses are over the network. Therefore, provide good, reliable bandwidth for access to eXtreme Scale. The overhead of remote access is mitigated by compressing the content in the grid (around 2.5x or 3x) so that it is served efficiently. With WebSphere Commerce, portions of the cache (the data caches) are assumed to be local to the application and are therefore create a large amount of traffic. We will also demonstrate how to tune this so that it is not a problem.
Figure 6-3 Example eXtreme Scale environment
We are going to highlight the main technical differences that will impact the design, configuration and management of a WebSphere Commerce deployment.
The architectural diagrams illustrate the benefits of moving to eXtreme Scale. Architectural differences highlights the main differences to consider specifically when moving the dynamic cache provider to eXtreme Scale.
Error 404 - Not Found
The document you are looking for may have been removed or re-named. Please contact the web site owner for further assistance.