Well, it depends. It is not commonly understood that XMPP is actually very modular. What I was citing you was the requirements for what you might call the "usual" XMPP server, what people tend to expect when they hook up Pidgin or Adium to something claiming to be an XMPP server for dedicated-client use. Huge rosters (in the hundreds is distressingly common, in the thousands not unheard of), server-to-server connections, avatars, conferences, frequent granular presence changes (some % of the users changing for every MP3 they play due to plugins), logging, etc.
On the other hand, throwing together a "shitty" web chat where no one chat room is expected to have more than, say, 20 users, where "chat rooms" are the only communication concept and rosters are more limited or perhaps nonexistent, no logging, sure, Node.js should definitely be able to scale to 100K no problem. Probably beyond with reasonable hardware.
I think you may be referring to Plurk's work, and please note I'm not calling their stuff "shitty", I'm specifically describing a minimal chat client up there. I actually don't think XMPP is all that much heavier than AIM or MSN (some, yes, but not really that bad), it's that IM has evolved past the days of ICQ. What kills you are the O(Roster Entry) elements; one guy with a 2,000 element roster (bidirectional) comes online. With XMPP, as part of the connection process you shove down the 2,000 user roster to the guy logging in, and have up to 2,000 other presence notifications to send out. And it's hard to make that entirely async; even if you do just grab the roster as a lump out of some data store, you still have to iterate over the 2000 elements of the roster to send out the presence updates, and even with GHz to play with that is going to take some time to formulate all the necessary messages. This is what would really worry me at the startup flurry I mentioned.
But like I said, you could still carry hundreds, most likely. Although even then I would observe that the value of having an XMPP server actually in-context to a Node.js process is really pretty minimal. You can still be a "part of the server" via the component protocol which is what you almost certainly really want. Let a best-of-breed do all that for you, and just implement the additional stuff you want in Node.js. Unless you're doing too many O(roster entry) things in there (which in general you aren't in a component), Node.js should scale quite well, and components can typically be sharded cleanly too (by assigning users to shards).
Well, it depends. It is not commonly understood that XMPP is actually very modular. What I was citing you was the requirements for what you might call the "usual" XMPP server, what people tend to expect when they hook up Pidgin or Adium to something claiming to be an XMPP server for dedicated-client use. Huge rosters (in the hundreds is distressingly common, in the thousands not unheard of), server-to-server connections, avatars, conferences, frequent granular presence changes (some % of the users changing for every MP3 they play due to plugins), logging, etc.
On the other hand, throwing together a "shitty" web chat where no one chat room is expected to have more than, say, 20 users, where "chat rooms" are the only communication concept and rosters are more limited or perhaps nonexistent, no logging, sure, Node.js should definitely be able to scale to 100K no problem. Probably beyond with reasonable hardware.
I think you may be referring to Plurk's work, and please note I'm not calling their stuff "shitty", I'm specifically describing a minimal chat client up there. I actually don't think XMPP is all that much heavier than AIM or MSN (some, yes, but not really that bad), it's that IM has evolved past the days of ICQ. What kills you are the O(Roster Entry) elements; one guy with a 2,000 element roster (bidirectional) comes online. With XMPP, as part of the connection process you shove down the 2,000 user roster to the guy logging in, and have up to 2,000 other presence notifications to send out. And it's hard to make that entirely async; even if you do just grab the roster as a lump out of some data store, you still have to iterate over the 2000 elements of the roster to send out the presence updates, and even with GHz to play with that is going to take some time to formulate all the necessary messages. This is what would really worry me at the startup flurry I mentioned.
But like I said, you could still carry hundreds, most likely. Although even then I would observe that the value of having an XMPP server actually in-context to a Node.js process is really pretty minimal. You can still be a "part of the server" via the component protocol which is what you almost certainly really want. Let a best-of-breed do all that for you, and just implement the additional stuff you want in Node.js. Unless you're doing too many O(roster entry) things in there (which in general you aren't in a component), Node.js should scale quite well, and components can typically be sharded cleanly too (by assigning users to shards).