Tigase Server, single machine - 109k authenticated connections
I had an opportunity to use 4 server like machines to do some load tests over the Tigase server. The Tigase server was installed on one of the boxes and the 3 others generated client connections and the traffic. As the subject says I achieved 109 707 authenticated connections before client software ran out of memory and the test finished.
Here are some statistics taken at the end of the test:
Tigase Server version3.3.2-b883
Concurrent, authenticated connections109 707
Test total time2h 40min 43sec
CPU usage (2 cores)95%
Total number of XMPP packets processed during the test45 058 717
Average packets per second processed8.7k/sec
Average server response time263 millis
Environment configuration - Pentium(R) D CPU 3.00GHz Dual Core, 4(server)2(clients)GB RAM, 144GB SATA HDD, 64bit CentOS 5.1, Sun HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode).
Tigase Test Suite was used for generating user connections and the traffic.
For more comments on these results please continue reading...
3.3.2-b883 is the new Tigase server version which will be released in coming days.
109 707 concurrent, authenticated users were connected to the server and the test stopped due to the clients software ran out of memory. I guess the test could go a bit further, maybe up to 120k?
Authenticated means that the connection was active and all the structures for the user session have been created and the user was generating traffic.
2.1GB memory consumption was higher than I expected as it was about 20kB per user connection. This is as much as twice more than in my old tests when the usage was about 10kB per connection. One of reasons of the higher memory consumption might be the fact that the test was running on 64bit platform with 64bit Java. 64bit Java is known to use more memory than the 32bit version. Another cause of higher memory consumption can be recent changes I made to the server code which could increase memory usage.
To be sure, however I would need to run similar tests under the control of the Java profiler. (This is what I did the last time).
CPU usage was something I expected after previous load tests. The load was caused by the messages passing the server and by the new connections being established, authentication, roster retrieval and so on....
263 millis server response time - during the tests there was a separate process querying the server for statistics. Every minute the process was connecting to the sever, authenticating and retrieving: server version, server configuration and server statistics. The whole process took 263 millis in average.