Administer > Dynamic caching > Prepare to use caching in WebSphere Commerce
Operate WebSphere Commerce in a production environment introduces complexities. For example, accessing cache entries that have been offloaded from memory introduces overhead associated with reading from and writing to the disk. Invalidating these entries is time consuming. Therefore, it is important to tune the cache using the available properties. By setting these values to the appropriate values, you improve the cache invalidation process. The second issue is cache replication. When WebSphere Commerce is in a clustered environment, you require a replication environment to share the cache entries between the different nodes in the environment.
Each WebSphere Application Server process has several parameters influencing application performance. By changing tuning parameters you can configure and tune applications.
IBM recommends that you first review the tuning parameter hot list in the WebSphere Application Server Information Center, which is a subset of the tuning parameter index. These parameters have an important impact on performance. Because these parameters are application dependant, the parameter settings for specific applications and environments can vary.
Each parameter in the tuning parameter index links to information that explains the parameter, provides reasons to adjust the parameter, how to view or set the parameter, as well as default and recommended values.
Delay offload entries limit
The htodDelayOffloadEntriesLimit property specifies the number of different cache IDs that you can save in memory for the dependency ID and template buffers. Consider increasing this value if you have a lot of memory in the server and to increase the performance of the disk cache.
The value of this parameter indicates how many items the index will hold. For example, a value of 1000 means that each dependency ID or template ID can have up to 1000 different cache IDs in memory.
The application of this setting to WebSphere Commerce is that there will be an index of this size on disk. You can access the indexed entries on the disk through the use of the index, without having to look for them.
Another parameter that you can set is htodDelayOffload (com.ibm.ws.cache.CacheConfig.htodDelayOffload). Having this property set to true indicates that the Application Server can use extra memory buffers for the dependency IDs and templates. This delays disk offload and minimizes the input and output operations to the disk.
The default value for this parameter is true. There is no need to set it to true, only to ensure that it has not been set to false.
Use this property to change the amount of time between disk cache cleanups.
If you have thousands of cache entries that might expire within one or two hours, the files that are in the disk cache can grow large and become unmanageable. Use the com.ibm.ws.cache.CacheConfig.htodCleanupFrequency custom property to change the time interval between disk cache cleanups.
Flush to disk
When the flushToDiskOnStop property is set to true, in-memory cached objects are saved to disk when the server is stopped.
In a production environment, it is common to have several application servers that form a cluster. In a clustered environment, it is advisable to setup cache replication so that the entries are shared between the different application server nodes. There are two different types of replication policies: Push and Pull. The table below contains a description of each:
Value Description not-shared Cache entries for this object are not shared among different application servers. shared-push Cache entries for this object are automatically distributed to the dynamic caches in other application servers or cooperating Java Virtual Machines (JVMs). Each cache has a copy of the entry at the time it is created. These entries cannot store non-serializable data. shared-pull Cache entries for this object are shared between application servers on demand. If an application server gets a cache miss for this object, it queries the cooperating application servers to see if they have the object. If no application server has a cached copy of the object, the original application server runs the request and generates the object. These entries cannot store non-serializable data. This mode of sharing is not recommended. shared-push-pull Cache entries for this object are shared between application servers on demand. When an application server generates a cache entry, it broadcasts the cache ID of the created entry to all cooperating application servers. Each server then knows whether an entry exists for any given cache ID. On a given request for that entry, the application server knows whether to generate the entry or pull it from somewhere else. These entries cannot store non-serializable data.
For WebSphere Commerce, using not-shared replication is recommended.
Cache monitor in a clustered setup
In a clustered environment, you need to configure each application server to have its own cache monitor. If the cache monitor is tied to the Web server, then we will not know which clone's cache you are monitoring.
To access the cache monitor through the application server directly, create a new Virtual Host. This Virtual host will have a host alias for each node running a cluster. Each alias should have as its hostname/port values the name of the node running a cluster member, and the port that the cluster member is running on.
To identify the port being used by a given cluster member, expand Servers in the left pane and click Application Servers. Click the server corresponding to that member, and then click Web Container. Click HTTP transports and note the port assigned to that container.
The cache monitor is installed to map to the application server cluster, and the new Virtual Host created above.