Caching is a very important aspect for any system to achieve high performance. Liferay Portal provides integration with different caching frameworks. Liferay Portal, by default, caches entity records, content, and so on.

 

Caching using Ehcache

Ehcache is a very powerful-distributed caching framework. Liferay Portal, by default, comes with the Ehcache integration.

The default configuration uses a cache on local instances. This means that if we are using a clustered environment, each node will have its own cache. 

 

replication using RMI

All the cache updates are replicated to other nodes using RMI. It is a kind of point-to-point connection between all the nodes in the cluster.

It creates a massive number of threads for replicating the cache over the cluster. Because of this algorithm, this option adds a lot of overhead and affects the overall performance of the system.

 

replication using Cluster Link

This option is available for the enterprise version of Liferay Portal.

All requests pass through a single place before they are actually distributed in the network, it gives a chance to remove unnecessary requests.

This feature reduces network traffic.

Internally, this feature uses UDP multicast to establish a connection with cluster nodes.

 

Caching using Terracotta

Another approach is to use the centralized caching server. All nodes connect to the centralized cache server and store/ retrieve cached objects.

we do not need to worry about cache replication. Terracotta is one of the leading products which provides this solution. Liferay Portal supports integration with Terracotta. If a portal is intended to have a large amount of cache objects and a large number of cache changes, it is recommended to go with this approach.

 

When we use Terracotta, we will not need any communication between individual Liferay Portal application nodes. Each node will directly communicate with Terracotta and store/ retrieve cached objects, sessions, and quartz data. It is recommended to use this architectural approach if the portal is going to have huge cache objects. This approach gives the best performance by omitting replication overhead.