Liferay Portal Performance Best Practices: To maximize the performance of your Liferay Portals you need to acquire best practices. By the end of this tutorial you'll understand making the most appropriate architectural decisions, fine-tuning, load testing, and much more.

As shown in the previous diagram, users of the portal will access the Portal using tablets, mobile devices, or through PC browsers. Liferay Portal 6.1 supports various devices, and we won't need any special component to render content for mobile devices. Liferay Portal can even detect specific devices and respond with device-specific content. Liferay also supports creating responsive web design using its UI framework called AlloyUI.

As shown in the reference architecture, every request will pass through Firewall. Firewall will filter unsecure requests. All valid user requests will be passed to the Hardware Load Balancer. The hardware load balancer is a hardware appliance which distributes loads between multiple web servers. The hardware load balancer can also deal with the failure of web servers. In case a of failure of any web server, the hardware load balancer diverts traffic to working web servers. There are a number of hardware load balancers available on the market. Some of the popular hardware load balancer vendors include F5, Cisco, Radware, CoyotePoint, and Barracuda.

The Web tier includes a series of Apache Web Servers. As shown in the reference architecture diagram, each Web Server is connected with each Application Server. The Web Server acts as a Software Load Balancer for Application Servers. Web servers can also act as components to serve static resources. The Apache Web Server connects with the Liferay Portal application server using mod_jk, mod_proxy, or mod_proxy_ajp connectors. These are popular connecters available with the Apache Web Server.

The Application tier includes one or more Liferay Portal application servers. Liferay Portal can be deployed on many different application servers. The reference architecture recommends using the most popular Apache Tomcat Server. Application servers are connected with web servers using the AJP protocol or the HTTP protocol. As shown in the diagram, there is a communication link between Application Servers. Each Application Server is connected with other Application Servers to replicate the session information, and cache and/or search indexes. Each Application Server is connected to dedicated Database Servers and Active Directory Servers.

The Liferay Portal server connects to the Database Repository tier. For production systems, it is advisable to set up multiple database instances with replication. Such a setup ensures high availability of Database Servers. Liferay Portal works with majority of open source and propriety databases. In our reference architecture, we will use MySQL, which is one of the popular open source databases.

Liferay Portal comes with an embedded Apache Lucene search engine. The Lucene search engine stores search indexes in a filesystem. As shown in the reference architecture diagram, each Application Server has its own search index repository in the Search Repository tier. Search engine repositories can be synchronized by the Liferay Portal server using the Cluster Link feature.

Liferay Portal comes with a media repository, which includes a document library, image gallery, and so on. Liferay Portal provides different options to store the media repository content. By default, Liferay stores the media repository content on a filesystem. It can be configured to store the media repository content on a database, Java Content Repository (JCR), CMIS-based repository, or Amazon S3. As shown in the reference architecture diagram, we have used a centralized filesystem to store the media repository content. To avoid issues related to concurrent access on a centralized filesystem, it is recommended to use Storage Area Network (SAN) as the centralized filesystem to store the Media Library content.

Liferay comes with its own user repository. Liferay maintains its user repository in a database. But for production systems, it is recommended to integrate the user repository with identity management systems. The reference architecture refers using the Active Directory server. Liferay Portal connects with the Active Directory Server using the LDAP protocol.

In the previous section, we learned about various tiers of the reference architecture. Let's understand how the reference architecture addresses architectural concerns.

In the performance benchmark test, Liferay Inc. used the following hardware configurations:

In the performance benchmark test, Liferay Inc. concluded the following:

We learned about the reference hardware and benchmark results. Now, let's size the deployment architecture for a sample project.

Both File System store and Advance File System store are similar with some exceptions. Both of these store files on the filesystem. Advanced File System stores additionally distributes files in a multiple folder structure to eliminate limitations of the filesystem. The File System store is the default repository store used by Liferay Portal. Compared to other repository stores, both of these stores give better performance.

Liferay doesn't handle file locking when we use any of these two stores. Hence on production environments, they must be used with Storage Area Network (SAN) with file locking capabilities. Most of the SAN providers support file locking, but this has to be verified before using them.

To get best performance results, it is recommended to use an Advanced File System store with SAN. In our reference architecture, we have used the same approach for the Media Library repository. Liferay can be configured to use the Advanced File System store by using the following properties in portal-ext.properties:

dl.store.impl=com.liferay.portlet.documentlibrary.store.AdvancedFileSystemStore
dl.store.file.system.root=<Location of the SAN directory>

This repository store simply stores files in the Liferay database. Concurrent access to files is automatically managed as files are stored in the database. From the performance point of view, this store will give bad results when compared to File System and Advanced File System stores. Also, if the Portal is expected to have heavy use of the Media Library functionality, then this repository store will also affect the overall performance of the Portal, as the load on the database will increase for file management. It is not recommended to use this store unless the use of the Media Library is limited. Liferay Portal can be configured to use the Database store by adding the following property in portal-ext.properties:

dl.store.impl=com.liferay.portlet.documentlibrary.store.DBStore

Java Content Repository (JCR) is the result of the standardization of content repositories used across content management systems. It follows the JSR-170 standard specification. Liferay Portal also provides the JCR store, which can be configured with the Media Library. The JCR store internally uses Apache Jackrabbit, which is an implementation of JSR-170. Apache Jackrabbit also, by default, stores files in a filesystem. It can be also configured to use the database for storing medial library files. For the production environment if we plan to use JCR, it must be configured to store files in the database. As on a filesystem, we can get file locking issues. The JCR store is a good option for the production environment when it is not possible to use the Advanced File System store with SAN. To configure Liferay to use the JCR store, we need to add the following properties to portal-ext.properties:

dl.store.impl=com.liferay.portlet.documentlibrary.store.JCRStore

Content Management Interoperability Services (CMIS) is an open standard that defines services for controlling document management repositories. It was created to standardize content management services across multiple platforms. It is the latest standard used by most of the content management systems to make content management systems interoperable. It uses web services and RESTful services that any application can access. Liferay provides the CMIS store which can connect to any CMIS-compatible content repositories. The metadata of the Media Library content will be stored in Liferay, and the actual files will be stored in the external CMIS-compatible repository. This repository store can be used when we need to integrate Liferay Portal with external repositories. For example, Alfresco is one of the leading open source content management systems. If we have a requirement to integrate the Alfresco content repository with Liferay, we can use the CMIS store which will internally connect with Alfresco using CMIS services. To configure Liferay with the CMIS repository, we need to add the following properties to portal-ext.properties:

dl.store.impl=com.liferay.portlet.documentlibrary.store.CMISStore
dl.store.cmis.credentials.username=<User Name to be used for CMIS authentication>
dl.store.cmis.credentials.password=<Password to be used for CMIS authentication>
dl.store.cmis.repository.url=<URL of CMIS Repository>
dl.store.cmis.system.root.dir=Liferay Home

Nowadays, companies are moving their infrastructures to the cloud. It provides great benefit in procuring and managing hardware infrastructure. It also allows us to increase or decrease the infrastructure capacity quickly. One of the most popular cloud providers is Amazon AWS. Amazon offers a cloud-based storage service called Amazon Simple Storage Service (Amazon S3). The Liferay Media Library can be configured to store Media Library files on Amazon S3. This is a good option when the production environment is deployed on the Amazon Cloud infrastructure. To configure Liferay to use Amazon S3 for the Media Library store, we need to add the following properties to portal-ext.properties:

dl.store.impl=com.liferay.portlet.documentlibrary.store.S3Store
dl.store.s3.access.key=<amazon s3 access key id>
dl.store.s3.secret.key=<amazon s3 encrypted secret access key>
dl.store.s3.bucket.name=<amazon s3's root folder name>

In case of transaction-centric applications, it is a good idea to separate read and write databases. In this situation, all write transactions will be executed on the write database and all read transactions will be executed on the read-only database. Using database replication mechanism, data from the write database is replicated to the read database. By using this mechanism, we can optimize the write database to perform extensive write transactions and the read database to perform extensive read transactions. Liferay Portal supports configuring read and write databases through portal-ext.properties. Here are some high-level steps to configure the read/write database through portal-ext.properties.

Database sharding is the architectural solution to separate the data of same the tables in multiple database instances. Liferay supports this feature. Liferay Portal can be used to host multiple portals within the same portal server using Portal Instances (Companies). By default, Liferay Portal stores data of all the instances in the same database. If we are hosting multiple portals using portal instances, the same tables will have data from multiple instances. Gradually, tables will grow rapidly because of the data from multiple portals. At some point in time, this will affect the performance as tables grow rapidly, and for any request internally the system will need to scan the data of all instances. We can configure multiple database shards (separate databases), and we can provide how shards should be chosen. Depending on the shard selection algorithm, each portal instance will be mapped to a specific shard database. By using this architectural approach, data from multiple instances will be distributed in multiple databases. By default, Liferay supports configuring three shards. But we can add more shards by changing configuration files. We can enable database sharding by changing portal-ext.properties. Here are some high-level steps to configure database sharding:

By default, shards will be assigned to each portal instance based on the round ribbon algorithm. Liferay also supports the manual selection algorithm. This algorithm allows for the selecting of a specific shard through the control panel. To enable the manual shard selection algorithm, we need to add the following property in portal-ext.properties:

shard.selector=com.liferay.portal.dao.shard.ManualShardSelector

Content Delivery Network (CDN) is a large network of servers deployed across the world to serve static resources. The same static resources are stored on multiple servers across the world. When these static resources are requested, they will be retrieved from a server nearby the location of user. This feature reduces response time drastically. Liferay Portal also supports integration with CDNs. In Liferay Portal, majority of the static resources are a part of themes. Liferay provides a way to rewrite URLs of static resources within themes to a URL of the same resource in CDN. By using this feature, we can also reduce the load on the Liferay Portal application server by reducing the number of requests. To configure Liferay with CDN, we need to perform the following steps:

This solution is highly recommended when the intended users are spread across the globe.

If we serve static resources directly from the web server, it can reduce the number of requests coming to the Liferay Portal application server. Also, static resources can be served faster from the web server than the application server. All portal requests pass through the web server. Hence, it is easy to filter static resource requests and serve them directly from the web server. To implement this option, we do not need to change any configuration on the Liferay Portal application. We need to copy all static resources from all the Liferay plugins to the web server public directory. We need to make changes in the web server configuration so that all the static resource requests are directly served from the web server public directory. In this approach, we need to ensure that we copy the static resources to the web server every time we deploy a new version. This option can be used along with CDN to serve static resources of portlets.

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. So in a clustered environment, it is required to replicate the cache across all the nodes. There are different options available to replicate a cache across multiple nodes. Here are the options available to replicate Ehcache across the cluster.

Ehcache replication using RMI

Ehcache framework supports cache replication using RMI. In this scenario, when the server starts up using IP multicast, each node in the cluster will connect with other nodes 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. The following diagram explains how each node connects with the other to replicate the cache:

As shown in the preceding diagram, we have four Liferay Portal nodes in the cluster. Each node is connected with each other. So in total, it will create around twelve RMI links to replicate the cache across other nodes. This option uses a thread-per-cache replication algorithm. Hence, 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.

Ehcache replication using Cluster Link

This option is available for the enterprise version of Liferay Portal. In this approach, Liferay Portal creates a limited number of dispatcher threads that are responsible for replicate cache over the cluster. As in this approach all requests pass through a single place before they are actually distributed in the network, it gives a chance to remove unnecessary requests. For example, if the same cache object is changed by multiple nodes, instead of sending two requests to all the nodes to invalidate cache, only one request will be sent. This feature reduces network traffic. The following architectural diagram explains this feature in detail:

As shown in the preceding diagram, all four Liferay Portal nodes are connected to each other using Cluster Link. Internally, this feature uses UDP multicast to establish a connection with cluster nodes. A small group of threads is created to distribute cache update events to all the connected nodes. It is recommended to use this option for Ehcache replication.

In the previous section, we talked about Liferay Ehcache integration. In order to use Ehcache in a distributed environment, we need to replicate the cache across the cluster. Another approach is to use the centralized caching server. All nodes connect to the centralized cache server and store/retrieve cached objects. In this approach, 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. Terracotta also provides solutions for storing web sessions and quartz jobs. By using Terracotta, we can even prevent session replication and replication of quartz job data. The following diagram explains how Terracotta fits into the Liferay Portal architecture:

As shown in the preceding diagram 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.

We have talked about the caching of objects at the Application tier. But in many situations, it is even possible to cache whole web pages and deliver them directly from the cache. This option can be used for content that doesn't change frequently. This approach can reduce the load on the web server, application server, and database server drastically, and also improve the overall response time. Such caching tools are also called web application accelerators. Varnish is one of the popular open source web application accelerators.

The following architectural diagram explains where Varnish can fit in our reference architecture:

As shown in the preceding diagram, the Varnish server runs in front of web servers. The Hardware load balancer will sent all the requests to the Varnish server. Based on the configuration, the Varnish server will decide if the request should be served from the cache or should be send to the web server. It provides a way to clear the cache as well. Depending upon the hardware configuration of the web server, it is also possible to run the Varnish server on the web server itself. This architectural option can be used with many portals which serves kind of static contents. Some of the examples include news portals and product catalogue portals.

Liferay Portal, by default, uses the embedded Apache Lucene search engine. Apache Lucene is the leading open source search engine available in the market. By default, Liferay Portal's search API connects with the local embedded Lucene search engine. It stores search indexes on the local filesystem. When we use Lucene in a clustered environment, we need to make sure the indexes are replicated across the cluster. There are different approaches to make sure the same search indexes are available to all Liferay Portal nodes.

lucene.dir=<SAN lucene index location>

Apache Solr is one of the powerful open source search engines. It is based on the Apache Lucene search engine. In simple words, it wraps the Lucene search engine and provides access to Lucene search engine APIs through web services. Unlike Lucene, Solr runs as a separate web application. Liferay provides integration with Apache Solr as well. To integrate Apache Solr with Liferay, we need to install the Solr web plugin. We can configure the URL of the Solr server by modifying the configuration of the Solr web plugin. It is recommended to use Solr with Liferay Portal when the Portal is expected to write a large amount of data in search indexes. In such situations, Apache Lucene will add a lot of overhead due to index replication over the cluster. As Apache Solr runs as a separate web application, it makes the Portal architecture more scalable. The following diagram explains the basic Liferay-Solr integration:

As shown in the preceding diagram, Apache Solr is installed on a separate server. The Apache Solr server internally stores indexes on the filesystem. All Liferay Portal servers are connected with the Apache Solr server. Every search request and index write request will be sent to the Apache Solr server.

In the preceding architecture, we are using a single Solr server for both read and write operations. Internally, the Solr server performs concurrent read and write operations on the same index storage. If the Portal application is expected to perform heavy write and search operations on the Solr server, this architecture as explained earlier will not give good performance. In such situations, it is recommended to use the master-slave Solr setup. In this approach, one master and many slave Solr servers are configured to work together. The master server will handle all the write operations and the slave servers will handle all read and search operations. Here is the diagram explaining the master-slave Solr setup:

As shown in the preceding diagram, we have one Solr master server and one Solr slave server. The Solr master server is configured such that it automatically replicates indexes to the slave server. Each Liferay Portal application server will be connected to both master and slave servers. The Liferay Solr web plugin provides a way to configure separate Solr servers for read and write operations. To scale the search functionality further, we can also configure separate slave servers for each Liferay portal node. This will reduce the load on the slave server by limiting search requests.