Chat server with websocket+node.js vs a native client with xmpp

Question

I couldn't find any reasonable benchmarks regarding comparison between a chat client that runs with using node.js chat server V.S. a client that works with xmpp.

I know node.js is async and as far as I know so does xmpp . However, my main concern is performance with same amount of concurrent users.

I would need this information to write an android app. Would like to know your opinions and advantages/disadvantages using both systems.

Thanks in advance.

Canadian

Do you have any idea about how many concurrent user will be expected? (roughly?) – Olvan

with node.js i think 4000 and if it is xmpp i am thinking most 2000 at the same hardware – Canadian

It depends on the hardware obviously, but if you're thinking XMPP would only support half the number of connections on the same hardware I believe you are wrong. Hard stats depend on the application and usage profile, but I know of single-server XMPP setups handling 4K easily. Even jabber.org runs on a single server, with 20K connections at peak usage. Given that you're saying you won't use many XMPP features, your application would probably get even further than a "normal" XMPP server such as jabber.org. – Gallardo

I too am curious as to why you think that you can only have 2000 users on the same hardware? Never mind that there is no reasoning to it being only half of node.js, the number seems pretty low anyway, unless your server is the android app ;-) Openfire was tested with 250K users on a single node (in 2008 none the less). – Bubonocele

Answer 1

While I understand what you're asking, you're attempting to compare a server-side Javascript implementation (Node.js) with a messaging protocol (XMPP).

There are many off-the-shelf XMPP servers, and lots of client libraries, already written. Since these are the concrete things you'll be working with you should be evaluating these if you are considering using XMPP, and then comparing it to other solutions to your problem.

If you implement something yourself on top of Node and websockets then you need to handle all the things that XMPP already provides, such as authentication, encryption, the application protocol, etc. as well as all the server-side routing logic. Many XMPP servers also support clustering - transparently running multiple servers behind a single domain.

Ultimately the choice is yours, as you know the most about your particular application. You should compare solutions not only on their single-node performance but also development time and scalability among other factors.

Gallardo

Sure MattJ, you are totally right about scalability. However, I need to know what performance differences are there between both platforms. The authentication, routing.. are not in my top priority list yet. – Canadian

My point is that they should be. Your application requirements should be decided up-front, and then performance questions about implementations should follow later. You'll also know then how much of an issue it is that Node.js+websocket may be missing some features XMPP provides. But if you do need XMPP's features, Google and Facebook are proof that it can scale successfully. – Gallardo

I have looked the features that xmpp provides. As i said, performance and concurrent total users per machine is more important for me. – Canadian

Answer 2

I have built a couple of chat services with Node.js for clients, and while I can say that it's easy to get a basic chat service running with Node.js, you will likely spend a lot of time reinventing the wheel if you choose to go this route. An XMPP server like eJabberd has a lot of built-in functionality you won't have to rebuild. Authentication, multi-user chat, moderation (kick/ban/ignore), user preferences, logging, etc.

For the projects I've worked on, eJabberd was certainly overkill, since they only needed the basics, but you should carefully consider your use case becore making a decision.

I'm thinking of creating a Node.js web client for XMPP, to make something akin to Campfire, but with eJabberd as its backend. I haven't actually committed to doing this, but I think it would be a nice way to get the best of both worlds.

Skimpy

Answer 3

It also depends on what kind of client you are writing: browser based clients use BOSH which is XMPP over HTTP, which uses long polling (similar to comet). This creates at least one request every 30 seconds (depending on settings) from each client, which starts to add up after you get a few thousand clients. I'd be interested to see a comparison on that - seems like web sockets should have an advantage there.

Unsteel

Of course, now you can use XMPP over websockets and get the best of both worlds. – Bubonocele