3 ms·

Isn't there also quite a difference in scalability? I would expect the Node.js version to support thousands users where is this version is probably only hundred

Isn't there also quite a difference in scalability? I would expect the Node.js version to support thousands users where is this version is probably only hundreds. Mainly just a curiosity question, I realize not many people will ever have to deal with thousands of concurrent people chatting.

KirinDave 17y ago
I don't know. I'd love to see an analysis of that. Do you believe Node.js can handle that kind of load? I'm probably going to extend this exercise by switching from the default contrib library networking and standard java.io, and instead use netty. I'm told that can give me superior performance and scalability, and I don't think it'd take much more code. But the rest of the code should be fine. I'm quite certain, from profiling, that the core data structures can scale to thousands (and even millions) of users. Clojure's refs and agents are extremely well-implemented. But, I'm not sure the node.js version really would scale to thousands of users. Every time someone connected hits enter the entire user set is looped over, synchronously. I suspect this latency will add up. The reason that code is so simple and direct is that everyone is just executing slices in one thread. In my version, the rooms have a thread pool (implicitly), so it really comes down to how many user threads java can allow.
- grayrest 17y ago
  > But, I'm not sure the node.js version really would scale to thousands of users. There are reports on the mailing of broadcast echo tests (which are basically the same thing) running 10k-20k concurrent users. The main problem seems to be running into OS limits for the number of open ports.
  - KirinDave 17y ago
    I'd like to see more concrete tests of that, but it sounds neat. I am fairly certain that the architecture USING the evented architecture wouldn't scale though.
- dhotson 17y ago
  The broadcasting loop shouldn't take too long... I'm pretty sure that the socket.send() calls are non-blocking. I could be wrong, I haven't tested my (toy) chat server that thoroughly. :-P In general, the single threaded evented model tends to scale better than the process/thread per connection model for large numbers of connections. Having to context switch between 10,000 threads/processes typically means the OS spends a lot of time doing context switching instead of IO. I'm not sure how Clojure implements agents, it may already handle having 10,000 concurrent agents efficiently. I'd be curious to know. Also, there's a great article about network programming, which you may have read. It's called "The C10K Problem", which talks about scaling to 10,000 concurrent connections. http://www.kegel.com/c10k.html http://www.kegel.com/c10k.html .. really good article, well worth a read if you haven't already.
  - KirinDave 17y ago
    > In general, the single threaded evented model tends to scale better than the process/thread per connection model for large numbers of connections. Having to context switch between 10,000 threads/processes typically means the OS spends a lot of time doing context switching instead of IO. Right, the evented model works, and you get that for free with Node.js. I dunno if that specific codebase would handle "thousands of users" though. Test it, it'd make a cool blogpost. :) > I'm not sure how Clojure implements agents, it may already handle having 10,000 concurrent agents efficiently. I'd be curious to know. Well right now it's 1 thread per connection, which I will have to change. As for agents, they dispatch on a threadpool with a number of threads corresponding to the number of cors in the physical hardware. So that part of the code should scale of fairly arbitrarily (although a specific room with many, many people may experience some latency, and many such rooms might bog down the thread pool).

KirinDave 17y ago

I don't know. I'd love to see an analysis of that. Do you believe Node.js can handle that kind of load? I'm probably going to extend this exercise by switching from the default contrib library networking and standard java.io, and instead use netty. I'm told that can give me superior performance and scalability, and I don't think it'd take much more code. But the rest of the code should be fine. I'm quite certain, from profiling, that the core data structures can scale to thousands (and even millions) of users. Clojure's refs and agents are extremely well-implemented. But, I'm not sure the node.js version really would scale to thousands of users. Every time someone connected hits enter the entire user set is looped over, synchronously. I suspect this latency will add up. The reason that code is so simple and direct is that everyone is just executing slices in one thread. In my version, the rooms have a thread pool (implicitly), so it really comes down to how many user threads java can allow.

grayrest 17y ago
> But, I'm not sure the node.js version really would scale to thousands of users. There are reports on the mailing of broadcast echo tests (which are basically the same thing) running 10k-20k concurrent users. The main problem seems to be running into OS limits for the number of open ports.
- KirinDave 17y ago
  I'd like to see more concrete tests of that, but it sounds neat. I am fairly certain that the architecture USING the evented architecture wouldn't scale though.
dhotson 17y ago
The broadcasting loop shouldn't take too long... I'm pretty sure that the socket.send() calls are non-blocking. I could be wrong, I haven't tested my (toy) chat server that thoroughly. :-P In general, the single threaded evented model tends to scale better than the process/thread per connection model for large numbers of connections. Having to context switch between 10,000 threads/processes typically means the OS spends a lot of time doing context switching instead of IO. I'm not sure how Clojure implements agents, it may already handle having 10,000 concurrent agents efficiently. I'd be curious to know. Also, there's a great article about network programming, which you may have read. It's called "The C10K Problem", which talks about scaling to 10,000 concurrent connections. http://www.kegel.com/c10k.html http://www.kegel.com/c10k.html .. really good article, well worth a read if you haven't already.
- KirinDave 17y ago
  > In general, the single threaded evented model tends to scale better than the process/thread per connection model for large numbers of connections. Having to context switch between 10,000 threads/processes typically means the OS spends a lot of time doing context switching instead of IO. Right, the evented model works, and you get that for free with Node.js. I dunno if that specific codebase would handle "thousands of users" though. Test it, it'd make a cool blogpost. :) > I'm not sure how Clojure implements agents, it may already handle having 10,000 concurrent agents efficiently. I'd be curious to know. Well right now it's 1 thread per connection, which I will have to change. As for agents, they dispatch on a threadpool with a number of threads corresponding to the number of cors in the physical hardware. So that part of the code should scale of fairly arbitrarily (although a specific room with many, many people may experience some latency, and many such rooms might bog down the thread pool).