Performance and clustering ejabberd vs. openfire

I just recently came over to openfire from ejabberd simply for the ease of configuration and great management and reporting features of openfire. Been enjoying what I’'ve found but when I mentioned to a friend I was using openfire instead of ejabberd he said:

“Ya, openfire is nice just it is no where scalable for large applications, they dont have clustering support and you’'re better off to use something that can scale better.”

For you openfire pro’'s out there, what say you? Just how scalable is openfire? Is clustering something on the horizon?

My personal use of openfire is a bot install, there will be less than a half dozen users, but those users will be getting pounded with traffic. Is openfire too juvenile to do what I want to do.

Hi,

for users with an Enterprise license clustering support may be developed, it’'s #2 of the voted issues on http://www.igniterealtime.org/roadmap.jsp

The abilitiy to add and replace nodes on the fly and to update software (kernel + product) without a downtime is a nice feature (while I don’'t know if ejabberd does also take over the established sessions) but one may be able to live without this. Especially if your company uses it only internal during business hours.

Creating TLS / SSL sessions is usually cpu consuming, handling traffic does not cause too much load on a server.

LG

Hey anthony,

As LG said we will soon start adding clustering to Openfire for the Enterprise edition. Anyway, clustering is primarily meant for high availability although it will also let you scale horizontally. In our internal tests we got to aprox 60K concurrent users (using a relatively old unix box) and stopped there since the load testing tool was not generating more load. Those users were sending traffic to the server every second or so which is not a common case. We got to that number using a single server and NO connection managers. We do know that the server can scale much more without CMs and even more when using CMs. If we consider that users do not send traffic to the server as frequent as in our tests then the number can go much much higher too. When using NIO idle connections are practically not consuming resources.

Do you know which is your expected load?

Regards,

– Gato

I believe the above specs would be adequate for what we are doing now. Just to verify clustering solves the issue of database replication as well or not?

Hey anthony,

Clustering of databases is not covered by clustering of Openfire. Enterprise quality databases provide their own clustering solution and I think that they will do a better job than us with their own products.

I think that each layer of the architecture has to provide its own clustering (HA) solution. HA means that the HA layer will appear to the “outside” world as a single entity. However this entity has the characteristic of quickly recovering in the case of an unexpected shutdown (i.e. fault-tolerance). Of course, a HA architecture will try to avoid having a single point of failure. That is why you will probably want to have HA in each layer of your architecture. So for instance, if you are using a webapp, openfire and a DB then each layer should have its own clustering solution.

Regards,

– Gato

Makes sense. One point of clarification, if using the internal database clustering will not be possible correct?

So, can you give any info about the timeframe for clustering support in the Enterprise edition? Is it a matter of resources or are there design problems?

Thanks.

Hi,

it’‘s on the roadmap and as far as I know it’'s in any case a matter of resources, no idea about the design.

LG

Hey Alex,

Feel free to contact me directly if you are interested in helping us with the clustering feature.

Regards,

– Gatp