Resolving LDAP-Liferay Performance Issue

Before we went live with a recent portal project we wanted to test our general performance and determine if the portal was capable of handling the expected load.  In our architecture, we're using Liferay as our portal framework, JD Edwards (JDE) is the ERP system, and we're using LDAP to manage and authenticate user profiles.

The testing…

As our portal was replacing an existing system we were fortunate that we could gather usage data from the previous portal via Google Analytics.  We also worked with the Business Analysts to determine our performance targets. With these targets in mind we recorded our test scripts using IBM's Rational Performance Tester (RPT).  The scripts simulated multiple users logging into the portal and navigating to several different pages simultaneously.

We ran the tests using a reasonable user ramp-up rate while maintaining our maximum user count for over 30 minutes in order to let the system stabilize.  We repeatedly ran the tests using a larger and larger maximum user count until we found the average page latency was greater than what we deemed acceptable. 

We had some more work to do before we could go live but at least the end users never had to experience this issue.     

The results come in…

Analyzing the test results, the biggest area of concern was the average amount of time it was taking for the users to login.  We knew generally that the login was slow but we didn’t know specifically what was causing the problem. To isolate the issue we added performance logging to the Liferay login code.  Throughout the login code we added additional logging information tagging the user session and timings before and after functional calls.  After reviewing the performance logging it was clear that the import of the LDAP record was our most time consuming operation.  

Turning off the import, however, was not an option as records could be updated not only from the portal instance but also directly through JDE.  Security being paramount, we had to ensure that user records were being kept up to date.    

The diagram below shows the two scenarios of how user profiles can be updated.  In the first flow (shown in red), a user updates their profile through the portal.  When the information is submitted to the portal, the portal calls a web service that updates JDE, which will then update LDAP.  In the second flow (shown in blue), a user's profile is updated in JDE, which then updates LDAP.  In both cases LDAP has updated with the latest accurate information. 

 

For every problem there is a solution…

After looking at previous user profile update trends we knew that most logins did not actually require a re-syncing between the LDAP and the portal.  We could not disable the import but perhaps we could add code to determine when an import was and was not required. 

Looking at the LDAP record we noticed that there was a last modified timestamp, which is only updated when the user record is modified.  We updated the Liferay portal user records and import process to include the last modified timestamp from LDAP.  After a user is authenticated against LDAP, the last modified timestamps in the Liferay portal and in LDAP are compared.   If the user profile’s last modified date matches, which is true most of the time, then the user profile is accurate and is not refreshed from LDAP.  In the event that the modified dates do not match, then the portal user profile is updated from LDAP.

We deployed the updated portal code to our testing environment and after the code passed our security regression tests we reran the RPT tests.  We were very pleased looking at the results of the tests.  By adding the last modified date to the user profile, we were able to significantly improve the performance of logins and eliminate the large average latency we had observed.  When went live we were confident that the portal could handle whatever the users could throw at it.



If you are looking for help on one of your own projects click on the link below.
http://www.mnpconsulting.ca/services/technology/performance-management



 

Setting up Liferay Clustering

Recently on a project there was the requirement to enable clustering between Liferay portal instances in order to replicate indexing. Without clustering a manually triggered re-index is needed for re-syncing.

This task proved to be more than trivial and so I thought I would share the steps I followed to get unicast clustering working.

Note: This guide was created using two Liferay instances running on Tomcat servers

0.) Ensure that communication is opened up between the two server instances over ports 7800 and 8080.

1.) Add the following line to the server.xml file:

<Connector port=”8080” protocol=”HTTP/1.1” redirectPort=”8443” URIEncoding=”UTF-8” />

2.) Modify tcp.xml file:

a.) Open the jgroups jar file found in the following folder /tomcat-<version>/webapp/ROOT/WEB-INF/lib
b.) Save a copy of the tcp.xml file outside of the jar. i.e. I renamed the file to new_tcp.xml
c.) In the <TCP> section of the new_tcp.xml file add:
     Singleton_name = ”liferay”
d.) In the <TCPPING> section tag update:
     initial_hosts="${jgroups.tcpping.initial_hosts:<server1-name>[7800], <server2-name>[7800]}"
     num_initial_members="2"
e.) Put new_tcp.xml file into your Liferay “classes” folder.
     /tomcat-<version>/webapps/ROOT/WEB-INF/classes/

3.) Update Portal-ext.properties with the following settings:

#clustering
cluster.link.enabled=true
ehcache.cluster.link.replication.enabled=true

#lucene
lucene.replicate.write=true
portal.instance.http.port=8080

#cluser.link.channel.properties
cluster.link.channel.properties.control=new_tcp.xml
cluster.link.channel.properties.transport.0=new_tcp.xml

4.) Download and install “Ehcache Cluster EE” plugin:

a.) Locate “Ehcache Cluster EE” plugin from the liferay market store. You will need to login to the liferay portal site and “purchase” the plugin (it’s free). Once the plug-in has been purchased you will have access to previous versions.
b.) With Liferay stopped put the downloaded plug-in package file in the Liferay deploy folder
c.) Restart Liferay