In the previous section, we learned about the Liferay Portal reference architecture. The reference architecture is generic in nature. It can be used as a reference to define an architecture that is more specific to a project. One of the important activities in defining a specific architecture is sizing. We need to be sure of the number of Liferay Portal application servers or web servers to meet performance expectations. In the beginning of the project when the system is yet to be developed, it is impossible to size the architecture with 100 percent accuracy. Hence, the idea is to size the architecture based on previous benchmarks, and then review the sizing during the load testing phase when the system is ready. Liferay Inc. publishes the performance benchmark for every major Liferay Portal release. It is a best practice to use this benchmark as a reference and size the deployment architecture of the solution. In this section, we will learn how to size the deployment architecture of the Liferay-Portal-based solution based on Liferay's performance benchmark whitepaper.
Note
This section refers to the Liferay Portal 6.1 performance white paper published by Liferay Inc.. This whitepaper can be accessed through the following URL:
The first step of the sizing activity is to capture some of the basic non-functional requirements. The following table provides a list of these questions. The answers to these questions will act as parameters for sizing calculations.
|
No. |
The requirement question |
Mandatory? |
Details |
|---|---|---|---|
|
1 |
How many concurrent users will log in at the same time? |
Yes |
Login is the most resource-consuming use case in Liferay Portal. It is very important to know the answer to this question. |
|
2 |
What is the number of concurrent users accessing the Message Board functionality including login? |
No |
The Liferay performance benchmark report publishes the result of this scenario. If the project requirement matches the scenario, we can use this to size the deployment architecture more accurately. |
|
3 |
What is the number of concurrent users accessing the Blogging functionality including login? |
No |
If such a scenario is applicable to our requirement, we can derive a more accurate deployment architecture. |
|
4 |
What is the number of concurrent users accessing the document management functionality including login? |
No |
Depending upon the project requirement if such a scenario exists, using this parameter we can size the deployment architecture more accurately. |
Once we get the answers to these questions, the next step is to compare the answers with performance benchmark results from the white paper and derive the exact number of application servers we will need. The whitepaper establishes linear scalability based on various tests. Based on the report, we can establish the exact number of application servers that we will need to handle a specific number of concurrent users. Before we jump on to the calculation, let us summarize the performance benchmark report.
In the performance benchmark test, Liferay Inc. used the following hardware configurations:
|
Server type |
Configuration |
|---|---|
|
Apache Web Server |
1 x Intel Core 2 Duo E6405 2.13 GHz CPU, 2 MB L2 cache (2 cores in total) 4 GB memory, 1 x 146 GB 7.2k RPM IDE |
|
Liferay Portal Application Server |
2 x Intel Core 2 Quad X5677 3.46 GHz CPU, 12 MB L2 cache (8 cores and 16 threads) 16 GB memory, 2 x 146 GB 10k RPM SCSI |
|
Database Server |
2 x Intel Core 2 Quad X5677 3.46 GHz CPU, 12 MB L2 cache (8 cores and 16 threads) 16 GB memory, 4 x 146 GB 15k RPM SCSI |
In the performance benchmark test, Liferay Inc. concluded the following:
|
No. |
Scenario |
Result summary |
|---|---|---|
|
1 |
Isolated logins: During this test, a number of concurrent users tried to log in at the same time. Based on this scenario, the breaking point of the Liferay Portal application server was identified. In this scenario, no customizations were considered and the Liferay login scenario with out of the box home page was tested. |
According to the results, one Liferay Portal application server was able to handle 27,000 concurrent logins at the same time. After , concurrent login requests if we increase the requests, the application starts becoming loaded and the response time increases. |
|
2 |
Login with Legacy Simulator: In this scenario a two-second delay was included in one of the home page portlets. As we build our application on top of Liferay Portal and we normally have some additional processing time after login for custom home page portlets, a delay of two seconds was included to simulate this scenario. This is the realistic scenario for estimating possible concurrent logins by a server. |
The results proved that the performance of the system degrades after 6,300 concurrent login requests. That means one application server should handle 6,300 concurrent login requests only. If expected concurrent users are more than 6,300 but less than 12,600 concurrent requests, one more application server should be added in the cluster. |
|
3 |
Message Board: In this scenario, a number of concurrent users will log in and perform various transactions on the Message Board portlet. |
It was proved that one application server was stable until 5,800 concurrent requests. After that, the system performance started to degrade. So in this scenario, one application server was able to handle 5,800 concurrent requests smoothly. |
|
4 |
Blogging: In this scenario, a number of concurrent users performed blogging transactions, such as view blog list, view blog entry, post new blog, and so on. |
The result proved that one application server was able to handle 6,000 concurrent requests smoothly. |
|
5 |
Document management: In this scenario, a number of concurrent users accessed document management functionalities. |
The results proved that the system was able to handle 5,400 concurrent requests smoothly with one application server. |
We learned about the reference hardware and benchmark results. Now, let's size the deployment architecture for a sample project.
The example Portal solution should be able to handle 15,000 concurrent requests. This is the only requirement that we received from the customer, and we need to size our initial deployment architecture based on that.
Login is the most resource-consuming operation in a Liferay-based portal. Also, the login use case takes care of authentication as well as rendering of the home page, which is displayed after authentication. We have not received any use case-specific performance needs. So for sizing, we can refer to the benchmark results of the Login with Legacy Simulator scenario. According to the results of this benchmark test, one Liferay Portal application server can handle 6,300 concurrent login requests. So to handle 15,000 concurrent login requests, we will need three Liferay Portal application servers. Generally, the load on the web server is less than 50 percent of application servers. Hence, we can derive the number of web servers as half of the application servers. So in our case, we will need two web servers (3 application servers/2). For the database server as per our reference architecture, it is recommended to have a master-slave database server. This calculation is valid for similar hardware configurations as it was used in the benchmark performance test. Hence, we need to use the same hardware configuration for the application server, web server, and database servers.