Home

Topologies

There are four topologies available for the WebSphere eXtreme Scale dynamic cache provider.

• Local

  This is the default behavior achieved when defining eXtreme Scale as the dynamic cache provider and is the topology that will always be used if cache replication is not enabled This option replaces the default dynamic cache service cache provided in the WebSphere Application Server with a local grid cache, with similar features and functions. It offers better performance than the default dynamic cache provider on large multi-processor enterprise servers because the eXtreme Scale code path is designed to maximize in-memory cache concurrency.

• Embedded

  The embedded topology is similar to the default dynamic cache when distributed across a cluster. Embedded cache instances keep a full copy of the cache within each Commerce process that accesses the dynamic cache service, allowing all read operations to occur locally. All write operations go to a single server in which the transactional locks are managed before being replicated to the rest of the servers. This topology is better for workloads where cache-read operations greatly outnumber cache-write operations. With the embedded topology, you are limited to the amount of cache you can store in a Commerce JVM.

• Embedded_Partitioned

  The embedded partitioned topology keeps all of the cache data within the Commerce processes. However, each process only stores a portion of the cache data. Most requests to the cache will be accessed remotely, resulting in a higher latency for read operations than the embedded topology. With this topology, the maximum size of the cache is not bound by the size of a single WebSphere process. Rather, it is the aggregate size of all the processes, minus the overhead of running the Commerce application. The embedded partitioned or remote topologies should be used when cache size requirement is greater than a single JVM and for workloads where cache-writes occur as often as, or more frequently than, reads.

• Remote

  With the remote topology, the cache data is stored outside of the Commerce JVMs, providing a deployment model where the amount of memory available for caching is unrestricted. Commerce JVMs do not perform the two distinct workloads of application serving and caching, improving the efficiency of the Commerce application and the caching infrastructure.

Use a remote topology with Commerce

For WebSphere Commerce, a remote topology, as illustrated in Figure 6-3, is usually the best choice. Commerce deployments typically require large (greater than 1 JVM) caches, so the embedded_partitioned and remote topologies are needed for scaling the cache size. Out of those two topologies, the remote topology offers the greatest flexibility to scale the Commerce and caching tiers independently and, as a result of moving the cache out of the Commerce JVMs, make the Commerce application servers more efficient. The other tangible benefit of using the remote topology is that the eXtreme Scale licensing is only required on the remote grid, which makes it a cost-efficient approach.

 

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.