Production environments
Operating 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 your environment.
Tuning parameters
Each WebSphere Application Server process has several parameters influencing application performance. By changing tuning parameters you can configure and tune applications.
First review the tuning parameter hot list, 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 your server and you want to increase the performance of your 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.
For more information, see Java virtual machine cache settings.Delay offload
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.
Cleanup frequency
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.
For more information, see Java virtual machine cache settingsFlush to disk
When the flushToDiskOnStop property is set to true, in-memory cached objects are saved to disk when the server is stopped.
Cache replication
In a production environment, it is common to have several application servers that form a cluster. In a clustered environment, cache replication must be enabled to maintain cache consistency between all application server nodes. Enabling cache replication helps maintain cache consistency by allowing invalidation messages to flow to all nodes using the Domain Replication Service. The following table describes the different replication policies that can be defined. The performance benefits and impacts of each replication policy may vary depending on your application configuration and shopper behaviors. Careful performance testing and measurement is recommended before deciding to use a replication policy other than the default "not-shared" replication policy.
| 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. |
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 you 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.