I did never run a Tsung test while Gato did run some tests. Your questions are not very detailed, and the same things I see with mosts test cases. Users which never change their status, no rosters and shared groups will improve the performance a lot but are far away from a real environment.
5000 is the number for Openfire 3.1 but with Openfire 3.2 / NIO the limit is much higher someone did mention 50000.
I don’‘t use Tsung and I’'m not interested in hosting a server for more than 2000 concurrent users. And most users will not have enough hardware to run tests as generating load is also CPU intensive.
You might want to look at this post by Gato, the lead Wildfire/Openfire developer. He was able to handle 30K connections on some pretty modest hardware, so 100K should be entirely doable with 2 or 3 connection managers on proper hardware. There was one report of an organization having achieved 20K connections prior to Wildfire 3.2.0 and connection managers using very powerful 64-bit system. So, it maybe possible to handle 100K connections on a single machine such as a Sun T2000 that is optimized for heavily threaded applications like Wildfire but I haven’'t heard if anyone has achieved that number of connections, although I would love it if someone did.
We worked with Gato to define a test configuration that could be realistic connecting a given number of users and changing regularly of status and exchanging messages.
We made different kind of tests depending on the rosters size.
As said in this post before, it is not really easy to have an idea of the traffic you will have. I would say it depends mainly on the following questions:
number of simultaneous users
rosters size (mean/max …)
type of connections (permanent or frequent disconnections - roaming user for example)
the previous question may be associated to the kind of users, do they change regularly their presence status.
Usage of MUC
So there are many questions and the only precise answers can be got in a real environment.
We can try to set some orders of ideas to make the test to be as close as possible to the reality but it is never exact.
I was able to simulate between 20/30K users with users using large rosters (lets say 150) with a medium message traffic and presence updates.
For that purpose I used a WF server (Xeon bi-dualcore 3.2 GHz 4Gb RAM) and an identical server for DB using Postgres. I connected the server to 3 CMs (Xeon Dual Core 2Gb RAM) loaded by 6 tsung clients.
It behave pretty well.
And just a final point to ryang, I was able to reach 80K users once (I have a snapshot) but the system was not stable and failed during high load. But it was before NIO and I bet we will reach this limit and go far above!
People who use Tsung should be VERY VERY careful in quoting connection stats directly from TSung.
It turns out that Tsung has a loose definition of what a connection is, and they include both failed connections and connections that just managed to get a TCP connect to go. I have learned this the hard way.
You should be sure that when using TSung, that you look at the error rates and correlate those with connections to get true numbers. Otherwise you are likely to quote numbers that are 4-5x higher than the boxes can actually handle.
every message has an overhead (body, receiver …) and is UTF-8 encoded so it can reach 200 bytes for 10 characters. But you may use compression and this should reduce the byte size again.
If your client is also sending typing notifications then you’'ll waste again a lot of bandwidth.