WXS Topologies with WebSphere Commerce
Local
Default behavior eXtreme Scale is defined as the dynamic cache provider. Used if cache replication is not enabled
A WXS local topology replaces the default WAS dynamic cache with a local grid cache, offering better performance as the WXS code path is designed to maximize in-memory cache concurrency.
Embedded
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.
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 best suited 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
- 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. 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 WAS JVMs
For WebSphere Commerce, a remote topology with WAS JVMs 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.