Liferay Performance Tuning

I have been in LA more than one month for a new employee training. I graduated on Jan 15th 2009, then start my first job at liferay

I like this company and all people here, i really have a good time in LA(In my big boss's home Thanks Brian and Caris!). My coworkers are very nice, My bosses are kindness and full of knowledge. I can learn a lot from them.

I am very happy to get this job, at here i can realize my dream


In this blog i will start to talk about my first project Liferay Performance Tuning. I hope this can help all my coworkers and poeple who are interested in Liferay Portal to understand the performance things. Trust me, liferay can run very fast! Let us start to speed it up together.

PS. Most of the information here are for developers, some of them are also helpful for end user. All the improvements mentioned here sooner or later will be included in our new release.

Preparation:

Before we start to tune our portal, we need a tool to tell us how good or how bad the performance is. We can call it stress test tool or benchmark tool(technically they are different, but here we just use them to represent a measure standard). I won't leak the really result number here, because we will formally publish a benchmark for our portal soon. So if you want to know the numbers, you have to wait

 

We are using The Grinder as our stress test tool. We define a series of test scenarios, then code them as Jython test scripts, run them on a batch of load injection machines. All the load are injected to a portal server which has a connection to a database server. The Grinder can report how good or how bad the servers can handle the injection, then we can find out the bottleneck and kill it.

So we do this by iterations: Create test scenario, setup Jython script, run stress test, find the bottleneck, kill the bottleneck.

Hardware environment:
   
    Portal server:
    CPU:     two 4 cores
    Memory:    8GB
    HardDiver: 10000 rpm
    NetInterface: 1Gb/s

    Database server:
    CPU:     two 4 cores
    Memory:    8GB
    HardDiver: 10000 rpm
    NetInterface: 1Gb/s

    Network:1Gb/s

Software environment:
    OS: Cent OS
    JDK: Sun jdk5 update 17
    Portal: Liferay Portal 5.1.x
    Database: MySQL 5.1

 

Our first test scenario: Login
    In this scenario we will hit the homepage, post to login, go to a private page(this page a has portlet which need 1 second time to render his view, to simulate the complex backgroup logic), sleep 5s(to simulate real user delay), go to another private page(as the first one, has a 1s delay portal), sleep 5s, go to the final private page(as the first one, has a 1s delay portal), sleep 10s, finally logout.
   
    The whole iteration would take about 25s. We will create a batch of client threads to run this scenario again and again, grinder can report the time using for each part of this scenario.

Setup the Jython script:
    We are using The Grinder's proxy recorder to record the user actions, then modify the recorded code to fit our scenario. Also we create some SQL scripts to setup the user accounts for login.

Run the stress test:
    We use a client machine to run The Grinder console, another client machine to run The Grinder agent with several hundreds worker threads. All the machines are connected to a 1 Gb/s network.

Ok, that is for today, next time we will start to tune the JVM first, then move on to find out the bottleneck for our first test scenario, Hopefully we can dig it out and kill it

Blogs
Welcome to Liferay, and I look forward to your posts! This will be a very useful series of articles.
That's interesting... But is it possible to see the results from your tests?

I think that this would be helpful in general, since there is not that much information on the net about the performance of Liferay...

On that matter it would be nice if Liferay would publish a Capacity Planning Guide - like the existing one for BEA WL Portal :-)

That would be helpful for the architects out there considering Liferay...