Skip navigation
2642 Views 6 Replies Latest reply: Dec 3, 2008 8:34 PM by Fingki Li RSS
Weihua Fan Bronze 6 posts since
Aug 14, 2008
Currently Being Moderated

Nov 26, 2008 7:44 PM

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.

http://www.igniterealtime.org/community/message/180605#

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.

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.

 

2.

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.

  • LG KeyContributor 5,935 posts since
    Dec 13, 2005
    Currently Being Moderated
    Nov 27, 2008 12:28 PM (in response to Weihua Fan)
    Re: Load Test on Openfire 3.5.2

    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

  • Gaston Dombiak Jiver 3,858 posts since
    Sep 26, 2001
    Currently Being Moderated
    Nov 30, 2008 10:53 PM (in response to Weihua Fan)
    Re: Load Test on Openfire 3.5.2

    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.

     

    2. 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

    • Fingki Li Bronze 7 posts since
      Dec 1, 2008
      Currently Being Moderated
      Dec 1, 2008 5:33 PM (in response to Gaston Dombiak)
      Re: Load Test on Openfire 3.5.2

      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

      • Gaston Dombiak Jiver 3,858 posts since
        Sep 26, 2001
        Currently Being Moderated
        Dec 2, 2008 9:58 AM (in response to Fingki Li)
        Re: Load Test on Openfire 3.5.2

        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

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points