Load Test on Openfire 3.5.2

I’ve been testing performance of Openfire 3.5.2 on my test machine these days.

I read a lot of posts here, especially those answered by Gato. Gato claims in several posts that he

has reached 250K concurrent users in a single JVM on a 64bit OS with 2GB RAM allocated to JVM.

I’m curious about Gato’s test and result in this post.

I can’t reach even 1/20 performance of what Gato archieved.

My test machine is a AMD64 4000+ 2G dual-core CPU, 3GB physical memory (2GB allocated to JVM), CentOS 5.2 64bit version,

no connection manager.

Database is PostgreSQL 8.3 installed on another machine.

“nofile” parameter of limits.conf has been changed to 22000 to avoid too many open files exception.

the JVM parameter is “-Xms1024m -Xmx2048m -server”.

The goal I wanna achieve is 100K registered user in DB, and 30K-60K active online users.

I use Tsung to test.

20K users in DB, each has 19 friends, no group. 6K users log in one by one every 0.01s. each user will get roster after log in, and then

send 1 presence per second. The test will last 30 mins, I tested this case several times and got only one success. All other tests ended with

OutOfMemoryError.

20K users in DB, each has 19 friends, no group. 20K users log in one by one every 0.01s. each user will get roster after log in, and then

send 1 presence per 5 seconds. The test failed in 48th mins, OutOfMemoryError.

Is my load too heavy?

I’ve also read a PDF document from Openfire, the “Openfire Scalability Enhancements”.

The doc mentioned extremely active users and users with low levels of activity, can someone define what is extremely active users and

what is low levels of activity?

I’ve also used JProfiler to find out the memory leak reason. I found that when in heavy load all byte[] object will used 1.2G RAM and didn’t

have a chance to be GCed, the OutOfMemoryError is throwed. while in low level load byte[] object could be GCed once in several seconds.

I have no idea why.

Please give me some advice here.

Hi,

did you use the standard GC or did you specify something like CMS as GC?

I’ve also used JProfiler to find out the memory leak reason. I found that when in heavy load all byte[] object will used 1.2G RAM and didn’t

have a chance to be GCed, the OutOfMemoryError is throwed. while in low level load byte[] object could be GCed once in several seconds

This sounds like a JVM problem, so you may want to decrease the load or use CMS or something else for GC.

LG

I’ve tried several Collectors(-XX:+UseConcMarkSweepGC or -XX:+UseParallelGC), but it seems none of them could solve the OutOfMemoryError when in heavy load.

Do you have any suggestions on how to tune the GC for Openfire?

Do you have any idea of how Gato test Openfire with Tsung? What kind of load did he use?

Hey Weihua,

I use Tsung to test.

  1. 20K users in DB, each has 19 friends, no group. 6K users log in one by one every 0.01s. each user will get roster after log in, and then send 1 presence per second. The test will last 30 mins, I tested this case several times and got only one success. All other tests ended with OutOfMemoryError.
  1. 20K users in DB, each has 19 friends, no group. 20K users log in one by one every 0.01s. each user will get roster after log in, and then send 1 presence per 5 seconds. The test failed in 48th mins, OutOfMemoryError.

Is my load too heavy?

Yes, I would say so.You are logging in about 100 users per second (I gues per client) and then each user is changing his presence every second. If you install the load statistics plugin you will be able to see that the incoming queues are getting filled up a lot faster than the server can process each request. That is what is making the server run out of memory.

I would recommend increasing the delay between your requests and create a more realistic scenario. Users do not change their presence every second or every 5 seconds. Since you have about 19 contacts in your roster you are basically flooding your network. Lets say that you have 10K logged users already. In a second they will send 10K presences that in turn will proximately imply 190K outgoing packets. As a first attempt, change the presence change to 5 minutes and see what the load statistics plugin show.

Regards,

– Gato

Hi Gato,

For the active users and the users with low levels of activity,

how many packages or requests will be sent per second per active user in your test ?

Can you tell me?

Regards,

– liqingfeng

Hey liqingfeng,

I don’t really the numbers from the top of my head and I do not have the scripts now at hand. But I do remember that the activity per user was based on average load (e.g change presence every 5-10 minutes, chat at a human spead, ~20 contacts per roster, etc.). Since XMPP ends up being a network activity you have to consider your network speed too. Client should read fast or otherwise the TCP layer will make the sender go slower thus filling up the outgoing queue. As I said, use the load stats plugin to see what is going on inside the server and easily identify what is causing possible out of memory problems.

– Gato

Thanks for your reply.