How-to: Testing and Tuning Liferay portals

The information in this article is for an outdated version of Liferay. Due to popular demand this article will stay accessible, but we strongly recommend to upgrade to a more recent Liferay version. Visit our contact page to learn about what our hosting solutions can do for your product.

Once the traffic to your Liferay Portal is increasing, performance starts to suffer. And instead of allocating more resources, the first thing that you should do is look for opportunities to optimize your Liferay Portal or as we call it: Liferay Portal performance tuning.

Optimizing your Liferay Portal is essential when your traffic is increasing because it makes you use your resources efficiently and you don’t want the user experience to suffer because of performance issues.

On a usual Liferay instance, you have a whole range of things that can be tuned to increase Liferay Portal’s performance, for example:

• Tuning of the Java Virtual Machine (JVM) startup parameters;
• Tuning of the application server (e.g. Apache Tomcat) setup;
• Tuning of the portal using Liferay’s properties;
• Tuning of the Database.

Preferably you want to change all of those, however in cases where you don’t have access to the configuration of the JVM or application server you still can achieve a lot by playing around with only the Liferay properties. Therefore in this blog, we’ll focus on performance tuning using Liferay properties only and see what significant improvement can be made.

Testing Preliminaries

For this test, I’ll be using a Liferay Portal CE version 6.2.2 GA3 running on our platform with 2 GB memory available for the JVM. To this Liferay Portal, I add multiple user accounts to be used for sending parallel requests to the instance during our tests. The tests themselves are performed using Apache JMeter which will also be used to collect and represent the results.

Testing Scenario’s

Tests will be run several times to see which improvements are achieved. First, a reference measurement is done of a vanilla Liferay Portal installation, this reference is then later used to compare the other scenarios with. In each scenario, two tests will be run:

1. Unauthenticated homepage views – This test will visit the homepage without logging in;
2. Login/logout actions – This test will only login, visit the homepage and log out.

Both tests will be run with 300 threads and each thread will run 100 times and the results are collected in a table and a chart.

Scenario 1 – Reference measurements

Portal Performance Test 1 – Unauthenticated homepage views

Figure 1.1 – Response time of the portal to requests (a subset of full data).

Figure 1.2 – Response time of the portal to requests (subset of full data).

Table 1.2 – Statistics on the response time of the portal to requests (full data set).

From the results above it also become apparent that the ‘Login action’ is also time (and resource) consuming. This is due to the fact that each time a user authenticates Liferay has to encode the user’s passwords and compare it to an encoded version stored in the database. By default, Liferay Portal v6.2 uses PBKDF2WithHmacSHA1/160/128000, for password encryption. It uses a keyed-hash message authentication code using SHA-1 and generates 160-bit hashes using 128,000 rounds. It is especially this high amount of rounds that is time-consuming. Of course one can choose to lower this number of rounds, but that would also lead to a less secure portal.

Liferay Portal Performance improvements

Now let’s apply some performance tweaks by changing some portal.properties (don’t forget to restart your portal for the changes to take effect):

com.liferay.portal.servlet.filters.sso.cas.CASFilter=false
com.liferay.portal.servlet.filters.gzip.GzipFilter=false
com.liferay.portal.servlet.filters.sso.ntlm.NtlmFilter=false
com.liferay.portal.servlet.filters.sso.ntlm.NtlmPostFilter=false
com.liferay.portal.servlet.filters.sso.opensso.OpenSSOFilter=false
com.liferay.portal.sharepoint.SharepointFilter=false
com.liferay.portal.servlet.filters.strip.StripFilter=false
session.tracker.memory.enabled=false

Most of these are for Single Sign On (SSO) setups and as we are (in these tests) not connecting to other systems, we don’t need SSO. There are also some properties like the Gzip and Strip filters which would decrease bandwidth usage. These are things you can better let a web server in front of Liferay do, allowing Liferay to focus on other things. The last property disables tracking user clicks. Since we do all the user actions in the tests this is also a feature we do not need here.

Scenario 2 – Tuned Liferay Portal properties

Portal Performance Test 1 – Unauthenticated homepage views

Figure 2.1 – Response time of the portal to requests (a subset of full data)

Table 2.1 – Statistics on the response time of the portal to requests (full data set)

Comparing the about 1.5 second page load time to the 2 seconds we had in the reference test, the property changes clearly resulted in a performance improvement of over 26%!

Portal Performance Test 2 – Login/logout actions

Figure 2.2 – Response time of the portal to requests (a subset of full data).

Table 2.2 – Statistics on the response time of the portal to requests (full data set).

Although it can be seen that the ‘Login action‘ in this scenario takes less time than it did in the reference scenario (which was already expected based on the results of Test 1 in this scenario), we see another interesting difference: the login time has also decreased significantly (over 25%).

So what can we conclude from this?

In the unauthenticated test, we saw an over 26% decrease in average page load time, quite a good improvement. Also note a 38% increase in throughput, which implies the server is also better at handling concurrent requests. For the authenticated test we also saw a similar decrease in average load time ~26% and an increase in throughput ~35%.

Another interesting effect can be seen if we compare the log out times: we actually see a performance decrease after tuning. However the ‘Logout action‘ takes such a short time (almost 100 times less than the reference ‘Load homepage action‘) it is highly influenced by other processes running on the machine that is running JMeter. Next, to that JMeter uses a resolution of 1[ms] by default, so a difference of a few milliseconds isn’t that significant.

As discussed above, changing properties can be used very well to increase Liferay’s performance. By only enabling features that you really need you can already improve performance with very little effort. It would probably also be a good idea to configure JMeter to use nanosecond resolution, just to inspect the ‘Logout action‘ in more depth (however keep in mind that this probably requires more resources).