OpenFire: Scalability, Clustering & Price

I am a xmpp dummy, so if my questions are out-of-scope (or funny), please answer anyway.

I am currently working on a new xmpp project… with 1 million or more of users…So scalability is the key for me. I need to select a xmpp server between the best existing. Obviously, OpenFire is shortlisted,

I do not expect to develop within OpenFire source code…But I would like to know the current capabilities of OpenFire server and use it as is.

Also, the little issue is that I do not understand the OpenFire pricing model…is there some documentation? or is it totally free ? is not that clear (whatever the xmpp server provider) in the xmpp forums.


I already read that there is a “Connection Manager” plug-in that can help to reduce the number of concurrent connections to the xmpp server. This raises new questions:

  • How many client connections can be handled simultaneously by the “Connection Manager”?

  • How many “Connection Manager” can be connected to one xmpp server?

  • Is it straitgh forward to deploy the “Connection Manager” ?

  • What is the price for each “Connection Manager” instance, OR is it free of charge?


Obviously, as we expect to deliver safely a service through xmpp, we want to have it safe …so I need a clustered solution.

First, I have a design question: Do we have Openfire stateless (everything in the database) or not ? having Openfire stateless would means “easier clusterisation”

Again, I read from this forum that clustering is tied to huge commercial constraints (Oracle). Is it always true? or did I miss something?

If clustering is a feature, do I need to pay for it?

To sum up, what would be the solution/price for a clusterered OpenFire supporting more than 1 million of of registered users?

Txs a lot for the answers,


Openfire is completely free and runs under the Apache licensing model. We also have a new FREE clustering option, thus a completely free software solution. This new clustering options (using Hazelcast) is not yet released but is available from a nightly build if you want to try it out (select your platform and drill down to artifacts). It does still require a central db for you cluster though, to answer answer your other question.

I cannot comment on your 1 million users use case as I have never dealt with that many users. BTW do you mean concurrent users, or simply the user total, as these are very different things when it comes to scalability. What these users will be doing will also have a large impact on scalability (chat, muc, pubsub, file transfer…).

You may also be interested in this recent thread.

1 Like

First, txs for the answer,

We currently have up to 1.5 million of registered users worldwide. We are mainly focused by the presence information, and depending on the number of deployed our free of charge client app (we do not force the end-users to install it), the number of concurent connection is probably somewhere between 10 times less and 10 times more…(ouch!!! could be if marketting strategy becomes viral). And, the aim of our future client app could be to activate/reactivate users (this mean then real connections). Before to choose a xmpp server solution, we have to think about all possible scenari.

Also, we could imagine having one OpenFire per domain (I assume it is an Openfire design rule), and one domain per big customer (up to 100K users)…with one OpenFire deployed per customer …Obviously, this would drastically reduce the number of connections per OpenFire…but this would mean maintenance cost for us

What about Connection Manager?

The connection managers were developed when Openfire was using one thread for each client connection. Now with NIO this is no longer the case.

I think one can use as many CMs as desired while I did never use one.

There were concurrency problems, I don’t know whether they are resolved now.