XMPP server : ejabberd vs openfire vs prosody

Having been involved in testing an open-source XMPP web client (JSXC) against ejabberd and Prosody, I have noticed the following differences. Please note that I have done more with ejabberd, so there will naturally be more nitpicking, but also more praise.

Ejabberd

Pros

  • The mechanisms that have been implemented are typically rock-solid, probably due to the fact that a company is behind it, offering services which require this quality.
  • With the ejabberdctl and the admin web interface, it is possible to configure many things while the process is running. Even if you need to touch the config files heavily, reloading them does the right thing without an interruption.
  • ejabberd can easily be turned into a cluster for reliability or performance
  • Comes with a built-in STUN/TURN server
  • Shared roster groups are very powerful, but also need getting used to.

Cons

  • The documentation is mostly option-based, i.e. options are described, similar to a manual page. There are few examples and even fewer descriptions of how the options interact, what would be the best practice usage, or actually where you would put the option, especially in a virtual hosting environment.
  • If you want to extend ejabberd, you need to be able to grasp Erlang, a very powerful language, but with quite a few differences to the programming languages most beginners learn.
  • External Service Discovery (extdisco) is not (yet) supported either.

Prosody

Pros

  • Has a lot of community modules, due to the easier accessibility of the Lua programming language.
  • As a pure community project, if you want to invest time, you really can shape the project.
  • Does support extdisco (requires less client configuration) and mam:2 (better supported by clients)

Cons

  • Some modules (for me, the most notable was the external authentication mechanism) are unreliable.
  • Has to be restarted for more configuration updates, i.e., clients will be disconnected and have to reconnect, typically causing has gone offline/come online notifications to the users. [Update: I did know about mod_reload_modules, which would have avoided some or these restarts. Thanks, drs!]
  • No persistence for PEP/PubSub (Personal Eventing Protocol; Publish-Subscribe) data. This makes it unusable for both bookmarking (e.g., multi-user chats) and XMPP-based social networks such as Movim

My Top XMPP server software

Top: Statistical use

  • 1) Ejabberd (61.6279%)
  • 2) Prosody (17.0543%)
  • 3) OpenFire (7.36434%)

Top: Multi-core use

  • 1) Ejabberd and Openfire

  • 2) --- !

Top: Memory usage

  • 1) Prosody
  • 2) Ejabberd
  • 3) Openfire

Top: Web-admin

  • 1) Openfire

  • 2) Ejabberd

  • 3) no (default)

Top: Programming language

  • 1) Openfire (Java) and Prosody (Lua)

  • 2) Ejabberd (Erlang)

Personnal / Raspberry pi / ejabberd vs openfire vs prosody = (‎My choice) Prosody

Statistical use (Russian Wiki):

http://jabberworld.info/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D1%8E%D1%89%D0%B8%D1%85_%D0%BF%D1%83%D0%B1%D0%BB%D0%B8%D1%87%D0%BD%D1%8B%D1%85_%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BE%D0%B2_Jabber

Review (Russian Wiki):

http://wiki.404.city/%D0%94%D0%B6%D0%B0%D0%B1%D0%B1%D0%B5%D1%80


If you are running your server on RaspberryPI i would choose Prosody. It is very lightweight and written in Lua.

Openfire is java and needs a good amount of resources to run, even in a small environment.

There are lots of minimalistic alternatives out there, but it all depends on what level of functionality you are seeking.

Tags:

Xmpp

Server

Recent Posts