Event description

Normally you would not call something a load test if there are just 40 user connections opened to the server.

This time, however the Tigase was running on the mobile phone which is itself an interesting achievement. One thing, however is to just run the application and another is to actually make it do something useful.

The Tigase running there was just the standard version you can download from the website, no single line of code was changed. And also the N900 was running all the standard applications as a fully functional mobile phone.

The only change I made to the phone was installation of the JRE and Bash shell, the rest remained unchanged and none of applications running on the phone was stopped.

All the connections to the server were established via mobile network and all the connections were encrypted with TLS.

 I am at the XMPP Summit/FOSDEM now. Thanks to people form Nokia we have an opportunity to play and run some software on N900 devices and thanks to Florian from Flosoft we have SIM cards for data transfer.

What is the most tempting thing for the software developer? Well, at least for me is to run my software on any possible device.

Taking the opportunity to use N900 and play with it I just had to try to run Tigase on it. I have already tested Tigase on small computers, Netbooks with ATOMs and small amount of memory. Tigase passes all tests when run with 10MB of memory so I was pretty sure N900 has enough memory and power to run Tigase.

Thanks to Directi Company who offered their hardware for Tigase tests I had a unique opportunity to do more detailed load tests under the Java profiler control. Good environment teamed with a good tools allowed me to find places where some optimizations are possible and further improve the Tigase server.

In my last tests, even though, the Tigase server was running under the Java profiler which consumes extra memory and CPU power I was able to achieve 152 584 concurrent, active connections.

In this test the client side software was the main limitation. I had only 3 machines to generate client traffic. In theory it allows to create maximum 3 x 64k connections. In practice it is slightly less. On top of this the client generators use more resources than the Tigase server as they are significantly less optimized.

As in previous test the hardware used to run Tigase server was: Pentium(R) D CPU 3.00GHz Dual Core, 4GB RAM, 144GB SATA HDD running on 64bit CentOS 5.1, Sun HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode).

Here are statistics taken at the end of the test:

The rest of the test parameters and all conditions stay the same.

I have had a great opportunity and pleasure to use Sun's environment both hardware and software to run load tests on the Tigase server for a couple of last weeks. Sun also ofered me something more. Their knowledge and help during the tests allowed me to improve Tigase and fine tune the system to get the best results. I would like to say great thank you to Deepak Dhanukodi, ISV Engineering from Sun who was a huge help.

Below is a description of the tests I run, environment and results I got.

Summary

I know summary should be at the end but I realize that many people may be interested in the results while not being interested in all the details. So here we go.

• The main goal for all these tests was to run the Tigase server under the load of 500k active user connections with an empty user roster. This test was going to show how well the Tigase server handles huge number of I/O and huge number of user sessions on a single machine.

  Success! The Tigase easily handled the load with CPU usage below 30% and memory consumption at about 50% level. The test was so successful that we tried to run another similar test to get to 1mln online users. This however failed because client machines couldn't generate such a load.

• Secondary goal was to run comparison tests with different user roster size for and user connections count above 100k to see how the roster size impacts the load and resources consumption.

  This test wasn't the kind of score max but still I think it is also a great success. At the roster size of 40 and above the Tigase server started to behave unstable. Long GC activities impacted overall performance and in some cases leaded to unresponsive service. More details below. I learnt not only that default GC is not a good choice for the Tigase server under a high load but also I found the best GC and GC parameters to get a stable service with even higher load than I planed before. The CMS GC is the one which should be used to run Tigase.

• Max connections and roster with 50 elements was the last test I wanted to run. In most XMPP installations I helped to setup, the average roster size was just below 50 elements. So the goal for this test was to see how many connections the Tigase can handle with such a roster.

  300k user connections with roster size 50 is the result which is quite good. CPU usage was below 50% and memory consumption below 60%. We could certainly try to handle more connections. Unfortunately I have never expected that the system can handle more than 300k user connections with 50 elements roster so this is what I had in the database prepared for the test.