Name: Caching in SAP Commerce Cloud
Uploaded: 2023-9-12
Duration: 883 s
Description: This video explains the working principle of the caching mechanism in SAP Commerce Cloud, as well as how to configure and customize caching.

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div>This video explains the working principle of the caching mechanism in SAP Commerce Cloud, as well as how to configure and customize caching.</div></div></div></div>

Caching in SAP Commerce Cloud

Welcome! In this video we’re going to talk about Cache.  This is a well-known concept and implementations of cache are widely used in many different scenarios.  A Cache is an intermediary component  designed to work between any process  and the data that it wants to access.   The Cache improves the performance of a server node by reducing the number of database queries.   It stores search results, item attributes  and item instances in memory, to provide faster access for other components.   It works like that:  Imagine that a user is requesting some resources from a server,  and that the server, in turn is retrieving  these resources from the underlying database or filesystem.   The database returns the resources  to the server,  which finally returns them to the user.   In a high concurrence scenario, we may end up  with a performance problem,  because the access speed to the database  or to the filesystem may represent a bottleneck.   Let’s see how the Cache implementation in SAP Commerce Cloud can help that.   In a scenario with a cache,  the user would likewise request the necessary resources from the server.   The server would also retrieve  the resources from the underlying  database or filesystem.   However, before returning the resources  to the user,  the server would first store them  into the memory cache  and only then return them to the user.  From that point onwards,  the server would find the resources in the cache and return them to the user without having to access the database or filesystem.   SAP Commerce Cloud comes bundled  with two Cache implementations,  both based in cache Regions.   The default one is provided by Ehcache,  which is a widely used open-source cache implementation. For compatibility purposes,  SAP Commerce Cloud also comes  with a legacy internal cache implementation.   As said before, you can divide the Cache in configurable regions.   In each Region you can configure  what items are cached, according to their deployment type code. you can configure the maximum size,  which will tell us how many items  can be stored in that region.  and you can configure the eviction policy,  which will tell us what item will be pulled off  the region to give room for a new item,  in case that particular region is full.   It is important to say that,  by default each SAP Commerce model is stored in the cache.   Also, each Flexible Search query  and its result list are also stored  in the cache.   A good measure to use it efficiently  is to avoid Flexible Search queries  with unnecessary small differences.   For example, don’t make queries with a range expressed by a timestamp if all you need are date ranges expressed in days.  SAP Commerce also has a decentralized  cache architecture.  This means that there is no main cache server.  All nodes have their own local cache.   Since all nodes are pointing  to a same database, it is important to have some means  to invalidate the cache across all nodes.  In fact, you can use JGroups TCP  or UDP messaging capabilities  to invalidate the cache across the cluster.   Let’s one by one review these concepts  with more detail.  When we say that the Cache is based  in configurable regions,  it means that it can define and control multiple areas in the memory,  each with its own rules.  In its default configuration, SAP Commerce Cache defines four regions:  One region to store Type System definitions.  One to store Query Results.  One to store Entities that don’t  fall into the other Regions.  And one to store Media Items.  Besides what elements can be stored,  in these regions, and in any others  that you may define, you can configure the region’s maximum size  and the Eviction Strategy  that will be applied there.  As for how and when items  are stored in the cache and invalidated from it,  let’s consider how it works  when dealing with Items  and with Flexible Search query results.  When accessing information that refers to  any Composed Type, the referred data  is returned from the cache.  If this data isn’t found in the cache,  it automatically retrieves it from the database.  When calling the save operation  in modelService, the cached value  is marked invalid.   This means that the next read operation  on that value will trigger a new fetch  from the database, so that the most up to date value is cached again.  If we execute a Flexible Search query, the result list is also stored in the cache.  When an item that is part of  such a result list is removed,  then not only the item itself,  but the entire result list that it was part of  is also removed from the cache.  After all, it wouldn’t make sense to keep a list with values that didn’t exist anymore.   When a cache region is full,  and there comes a request to store a new element, the Eviction Strategy is the logic  that determines which of the stored elements  will be removed from the cache  to make room for the new one.   The three Eviction Strategies available out of the box in SAP Commerce are:  First In First Out, that will evict items in the same order by which they were stored.  Least Frequently Used, that will remove items with the lowest hit rate.  And Least Recently Used, that will remove items not accessed by the longest time.  Let’s review the configuration for the standard regions in SAP Commerce Cloud:  As expected, the Type System Definitions region should always be available.  Thus, it can safely be defined  with neither a limit, nor an eviction strategy,  since it won’t grow dynamically.   By default, SAP Commerce Cloud  will store twenty thousand Query Results, and the first result that was stored  will be the first one removed, if necessary.  It will also store one hundred thousand entities in the cache,  also by the first-in-first-out eviction strategy.   Finally, the size limit of the Media Items region will not be expressed in number of items, but in megabytes. And it just makes sense that, at any given time, media items that are being used be kept in the cache,  while the least recently used items are removed Let’s see that in practice.  In the Administrator Console, under Monitoring,  and Cache, you can monitor the state  of all the cache regions.   As we can see, all the regions that we mentioned are here,  and many others that were defined in this instance. If we expand any of these regions,  like the Entities Region here,  we can see this region’s max size, the hits,  the misses, and other relevant information.   We can also see here the “Clear cache” button.  If we click on this button, you can see  that the entire cache is cleared.  There aren’t any other elements stored  in it at this point.  But we can also see that some new elements  begin being stored,  probably by background processes  that are active at this moment.  Now let’s access the storefront.   It relies on many entities,  and as it’s being loaded,  we can see that the Entities region is being populated again.   Notice that at first the entities were not found in the cache,  but after they were retrieved from the database, they were cached once again.   All subsequent accesses to the storefront  will now find these entities in the cache,  that is in the memory, as we can see from the rising Hits,  without further Misses.   We can also filter the entities being monitored.  If we filter the User type, we can see that there  are already some users or employees  cached in the system.   Then, if we go into Backoffice   and look for the Employees,   we can see that now there are many more instances of the Employees  in the cache,  since they are all a subtype of User.   Once again, all further requests to the same entities will be returned from the cache, and not from the disk.   Finally, we can also verify the same behavior  with Flexible Search Queries.   If we run a query, selecting all products,  for example, we can see that the first execution takes some time.  But if we run the same query again,  the Execution time will be shorter,  thus demonstrating that the result  is now being fetched from the cache. As we have just seen, there were more than the four standard Cache Regions in the server.  Indeed, we can not only change the configuration of the existing regions,  but we can also define new ones,  such as a Products region, for example.  It might be interesting in case  we had a very high access rate for products.  Or a Manual Region, for caching other kinds of items.  In this case, we defined both new regions  with a maximum Size of fifty thousand items,  and Least Frequently Used as the Eviction Strategy.  We can use the local.properties file to change predefined settings of an existing Region.  For example,  we can use this predefined property  to change the size of the Entities Region  from one hundred thousand  to fifty thousand elements.  or this one to change the Eviction Strategy.   Different regions may expect different  kind of parameters, such as the maxSize property in the Media Items region.  As we’ve just seen,  we can change the configuration  of existing Regions by use of properties.  These properties are handled by the PropertyPlaceholderConfigurer.  It allows cache settings defined  in the core cache configuration,  or in any other extension, to be changed in the local.properties file. For example, in this XML code, we can see the configuration of the Entities Region. Despite the definition of this region being inside the Core Cache configuration,  It gives you control of some of its settings by defining them as parameters that can be changed in the local.properties.   After we restart the server, the new values of these properties are applied to the Cache configuration. On the other hand,  if we want to create a new region,  we need to do that in the Spring Global context. In this example, we are defining a Spring Bean representing a new Cache Region  named productCacheRegion.  We define the bean type as EHCacheRegion.  We can also define the Region’s Name,  Size Limit and its Eviction Strategy.  And finally, in the handledTypes property we define a list of the item types that should be handled by this new Region.  We use the deployment code of these types to do that.   Now that we understand what happens  inside the cache,  let’s look at how it works in a cluster scenario.  A typical server cluster contains many nodes,  all connected to the same database server.  Let’s also consider that each server node contains its own cache.  When this server cluster receives requests  from different users,  the load balancer will assign each user  to a single server node.  From that point on, each one of them  will keep accessing the same server node.   We’ve seen that, if a user wants to retrieve a Product, and it isn’t found in the cache, then this Product will be retrieved  from the database and stored  in the local cache.  All subsequent requests from this user to this Product will be returned from the cache.  However, if a different user tries  to access the same Product  it will not be found at the cache  on the server node assigned to that user.  So,it will have to be retrieved from the database and stored in that node’s cache.  Now, if that user somehow changes  this Product’s attributes,  and persists it to the database,  it is clear that the cached instances  of this Product are now outdated.  Accessing them would lead to inconsistencies.  That’s why each save operation  on any item triggers an invalidation  to that same item that might be stored in the cache in any server nodes in the cluster.  It’s worth mentioning that inside a single VM the invalidation is made by a method call,  while the cache in other server nodes  is notified by a network message.  SAP Commerce uses JGroups for defining the server nodes participating in a cluster  and for exchanging messages between them.  You can use TCP if you want,  but we recommend using UDP multicast, which is faster. The use of JGroups provides  the faster communication across server nodes,  and it supports having server nodes either local, or in the cloud, or a mix between them.  If you need to change JGroups settings  for your cluster,  you can find these settings  within the platform folder.  You can find there a file for configuring TCP settings, and one for UDP.  SAP Commerce Cloud also supports caching of CMS Components.  However, this feature is disabled by default,  and should only be used if necessary.   It is also based in a Region Cache.   Since CMS Components may be personalized  and tied to a product,  a user or some other type,  the Cache key used to access these components can be customized.  If you need to enable CMS Component caching, you can also do that in the local.properties.  And its other settings can also be defined there. Out of the box, we have four default cache key providers:  The Default CMS Cache Key Provider will store an item with a key based on its PK,  its modification time, its currency, its language  and any component restrictions.  The Current User CMS Cache Key Provider  extends the default implementation  and allows caching of CMS items  tied to the current user.  The Current Product CMS Cache Key Provider  is used to cache CMS items related to a product thus, it is usually used only in Product Pages.  The Current Category CMS Cache Key Provider is used to cache items in Category Pages. An important thing to take into consideration is to properly define the size of the cache.  However, the size of the Java Heap may not be the same in the different environments, such as development, quality assurance and production. Therefore, instead of using fixed values,  we recommend that you either have a different local.properties file for each environment,  or that the Cache is configured in a flexible way. For example, for the Entities Region, as a rule of thumb, we recommend you to use a formula that takes the current memory size  into consideration.  This example is configuring the size  of the Entities Region as a dynamic function  of the current memory.  This video explained how the Cache implementation in SAP Commerce Cloud works, and how to redefine and configure it.  Thank you!