powered by Jive Software

Wildfire Limitation/Capabilities List?

Hi, I’'m new here and would like to ask some questions.

I would like to ask if there is a recommended server (hardware) and OS that best run Wildfire/OpenFire?

Also, what are the limitations of:

  • Maximum # of messages that can be transmitted by server at time X (assuming there are hundreds of thousands of users).

  • Maximum # of messages stored offline (where users retrieve offline messages from).

  • CPU/Memory usage of Wilfire / OpenFire.

Also, about the gateway/transports:

  • Assuming message goes from Yahoo to Wildfire to desktop client, how much CPU/memory would that add from bullet 3 above?

Can I also transfer files between Yahoo/MSN/AIM/ICQ/XMPP? I tried with Yahoo and couldn’'t get it to work.

Thank you.

anyone knows? please help. I can’'t find any docs about these. have there been tests or recommended setup hardware/software?


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.


hi thanks for the response.

Might I ask then, assuming everyone changes their status once every 20 minutes. How does one test that?

I am new in this, and would like to know how to test with Tsung (did a google…didn’'t know how to use it).

What are your test environment and result? What max. user online did you get for Wildfire/Openfire? I read somewhere it’'s 5000 users only?



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.



by 50,000 users, does this mean one server? So if I used 2 connection

managers, it’'ll be 100,000 users (2 connection manager, and 1

main openfire server)?

i could not get connectionmanager to work also…is there a guide


do you know who got to test it on 50,000 users (or the topic link

here in forum)? so i can ask

thank you.

Hi meow,

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.

Hope that helps,


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!

Hi Cohen,

Thanks for sharing your experiences and specs.



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.



i see. it seems no one has really tested it aside from using Tsung.

how about bandwidth…how to know how much bandwidth is consumed

by, say, sending 1 message to another user (assuming 10 char message

is sent).


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.


A message may look like