I've gotten quite a few questions on the just announced WebSphere eXtreme Scale integration with WebSphere Commerce Server. One of the top themes is around CPU usage.

Duplicate Page Rendering

This is the first major saving. A WXS cache is a separate tier and is shared between all the Commerce server JVMs. Once any commerce JVM renders a page fragment and stores it in the WXS tier then that fragment is immediately available to every other Commerce JVM. If there are N Commerce JVMs then that means the page fragment will be rendered once instead of N times. This is a significant source of CPU savings in the following circumstances:

• Commerce JVM cold start

Here when the commerce cluster starts initially, normally every JVM renders every fragment. With WXS, each fragment is generated once only, this allows the commerce cluster to get warm much faster than before with less CPU burned.

• Commerce JVM warm start

Here, when a Commerce JVM is cycled for maintenance or restarted after a period of being down, there is no need to rewarm its cache when using WXS. The cache is already warm when using WXS because the cache doesn't live within the Commerce JVM at all.

• Invalidation scenarios

Here, when fragments are invalidated, fragment only get rendered once instead of N times.

Cache management costs

Commerce Server using a private disk based cache normally. This cache is private that means the burden of managing that cache is borne totally by that Commerce JVM. The bigger the cache, the more management, the more garbage collection pauses, the more private disk I/O and so on. This cost is per JVM so N JVMs means N times this cost.

A WXS cache is not managed by the Commerce JVMs at all, the costs of managing the WXS cache is shared by the collection of JVMs hosting the grid. This removes this CPU cost from the Commerce cluster and makes that CPU available to do more useful things like sell products. In addition to this CPU saving, WXS scales linearly, no one JVM is responsible for the cache management tasks, the tasks are shared in a uniform manner between all the JVMs hosting the data. There is no single bottleneck. If you make the cache larger then add more JVMs to increase capacity, add CPU for cache request servicing and management and network. We can say that the cost of management for a single WXS JVM stays constant as the cache cluster grows in size. We move the cost of managing the cache away from the client application and in to a more scalable tier.

Summary

So, there are two principal CPU savings. 

• WXS eliminates redundant page fragment rendering in startup and invalidation scenarios. 
• WXS removes cache management costs from the client application tier (i.e. commerce) and makes them constant cost per cache tier JVM as the WXS tier grows.

If you have any other questions then please comment and I'll write up responses on the blog.