Book Image

Liferay Portal Performance Best Practices

By : Samir Bhatt
Book Image

Liferay Portal Performance Best Practices

By: Samir Bhatt

Overview of this book

Liferay portal is the leading horizontal portal product available in the market. It was named lLeader in Gartner's Magic Quadrant for Horizontal Portals. Because of the flexibility offered by Liferay Portal for customizations, it is becoming a preferred best choice for portal implementations. Many influential sites have been implemented with or have switched to the Liferay portal. More and more Liferay developers and architects are needed in the IT industry.Liferay Portal Performance Best Practices will guide you in how to build high performing Liferay -based solutions. The book guides you on how to define the architecture of Liferay- based solutions to meet performance expectations. You will learn how to fine- tune the Liferay portal using configuration changes or applying the right caching strategy. By the time you finish reading, you will realize that you know all the essential best practices to improve the performance of the Liferay portal solution. The book comprises of Liferay portal performance best practices related to various aspects. It starts with the architecture and design best practices and ends with performance tuning and lLoad testing best practices. The book follows the logical flow. In the first chapter it talks about various architectural options and best practices. It also talks about the consequences of various architectural options. It talks about how to configure the Liferay portal to work in a clustered environment. It discusses the various options available in a cluster configuration. The book further talks about various configuration options of different components that are available for improving performance. The book also talks about various development best practices. It concludes with best practices related to load testing and a performance tuning exercise. Liferay Portal Performance Best Practices explains performance best practices with real examples and samples. By the end of this book, the reader will have learned everything he/she needs to know about Liferay portal performance best practices.
Table of Contents (13 chapters)

The Liferay Portal reference architecture


Defining the architecture of a system from scratch requires an enormous amount of effort for researching, investigating, and taking right architectural decisions. We can reduce the effort by referring to the reference architecture for similar kinds of solutions. We can also ensure including a set of architectural best practices from the reference architecture. In this section, we will talk about the reference architecture of Liferay-Portal-based solution. This reference architecture can be used as a base for any Liferay-Portal-based portal solution. Of course, necessary changes have to be made in the reference architecture depending upon specific requirements. The rest of the chapter will help Liferay architects to make the right architectural decisions for such changes.

Here is the reference architecture diagram of Liferay-Portal-based solution:

The Presentation tier

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.

The Networking tier

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

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

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 Database Repository tier

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.

The Search Repository tier

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.

The Media Repository tier

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.

The Active Directory tier

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.

Reference architecture characteristics

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

Scalability

As shown in the architecture diagram, horizontal scaling is used for both the Web tier and the Application tier. Most of the components in the architecture are decoupled and hence if the user base is increased, we can scale up by adding extra nodes. We can establish linear scalability of the solution by using a performance benchmarking exercise. This can enable us to increase the capacity of the system by increasing 'x' number of Liferay application servers, web servers, or database servers.

Performance

The reference architecture divides the load of the system to multiple tiers. A static resource's requests can be served by the Web tier directly. Also, the Web tier is load balanced using the Hardware Load Balancer. So, the load on each web server is also controlled. Similarly, all application requests will be served by the clustered Application Server tier. The Application Server connects with the Database tier which is again clustered to ensure the load is distributed. The reference architecture ensures that the architecture of the solution is robust enough for delivering high performance.

High availability and fault tolerance

The reference architecture ensures that the most important tiers of the solutions are clustered and load balanced to ensure that the system is highly available and fault tolerant. As shown in the diagram, the Web tier, Application tier, and Database tier are clustered, which means that if any nodes from these tiers go down, the system will still respond to user requests.

Security

The reference architecture places Firewall in front of the Hardware Load Balancer, which ensures that all the security threats are filtered. Depending upon the security needs, it is advisable to set up a firewall between each tier as well. So for example, the Web tier can access the Application tier, but the opposite can be prevented. Depending upon the project need, the architecture supports configuring SSL-based access.