SAP Commerce uses Ehcache for caching objects like DTO’s for the OCC layer in memory, the downside of the usage of Ehcache is that the cache is just tight to a single SAP Commcer node. If the composition of the data is an expensive/slow process you will not be able to use the per-computed cache values across the different cluster nodes, here Ehcache Replication can help.
SAP Commerce uses internal Jgroups to drive cluster communication between the cluster nodes in an SAP Commerce environment. Depending on the currently hosted infrastructure Jgroups uses TCP or UDP communication. If you are hosted at a public cloud provider like Google Cloud Platform, AWS, or Azure you will need to use TCP communication as UDP traffic is usually prohibited there. The same applies to SAP Commerce Cloud in the public cloud as this is hosted on MS Azure infrastructure.
Jgroups Replication
SAP Commerce 2211 uses Ehcache 2.10.6 internally as part of the core platform extension, Ehcache-JgroupReplication is still at version 1.7 which doesn’t align with all the changes of Ehcache for a long-time.
How to improve API cache hit ratio across a cluster?
One way to improve your cache hit ratio in your cluster is to use a different technology to persist the cached content, like a central Redis instance, which you need to purchase as part of your own cloud subscription at Azure (see Link). As this needs to be purchased externally you will need to pay for it on top of your existing SAP Commerce Cloud in the Public Cloud (aka. CCv2) – subscription.
If you want to use the Spring framework-provided capabilities in SAP Commerce Cloud to cache responses of your API’s then you should stick to the Ehcache-provided capabilities.
What changes are required to distribute Ehcache content?
With our provided extension EhcacheReplication you will be able to enable replication between the different SAP Commerce nodes, check out the content at https://github.com/rubicon-consulting/Ehcachereplication.
The new extension will address the incompatibility issues with the old ehcache-jgroupsreplication Jar.
Check out the extension and add it to your custom code base and add it to your localextension.xml file. To monitor the improvements and functionality of the Ehcache content replication via Jgroups we recommend adding our Ehcachehac extension to the system as well, see also our Blog post about this extension.
Configuration steps to enable Ehcache replication
Add the extension to your localextensions.xml
Select the ehcache.xml for the CommerceWebservice extensions which matches your SAP Commerce version, overwrite the property based on the provided samples in your local.properties file.
Review and adjust the provided ehcache.xml files to reflect your specific TTL and eviction settings.
Rebuild your SAP Commerce app and deploy it.
Depending on the used Jgroups communication of SAP Commerce the extension will create a new Jgroups channel via UDP or TCP.
If it is UDP then you can change the UDP via properties in your local.properties to establish the new Jgroups channel with a different UDP address or port.
If you are using TCP then you can just change the port of the new Jgroups channel as the IP address will be determined like the standard SAP Commerce adapter IP address. This will ensure that the setting also in SAP Commerce Cloud in the Public Cloud aka CCv2 works as these values will be managed by the automation engine.
Performance test results with Ehcache replication enabled
If you run a performance test against your environment you can see how the number of cache entries is increasing across the cluster nodes.
In the example below we run a test against the OCC product data endpoint to fetch all product data of the electronics product catalog.
At the beginning, both nodes in the test scenario show zero instance count and zero hits and misses.
The second node at the same time also shows zero instance count and no hits or misses.
After loading all the product data we can see at the first node which was serving the requests, that we now have an instance count of 183 with all misses as the cache was empty in the beginning.
The second node shows after the test run we can see that the cache at node 2 also has 183 as the instance count but no entries were fetched from it, which leaves the hit/miss count still at zero.
After the execution, it is also obvious that the cached content at both nodes is the same. See at node 1 we have some cache hits after the second run against that node.
The second node has the same content as the first node and as we executed the same test against this node we have only hits for the cache right from the first test execution.
I want to know more about how Ehcache Replication works?
Do you want to know more about Ehcache Replication and how it can help your project to achieve better performance, request a complimentary consultation with our expert via the below form.
Request a complimentary consultation