3 ms·

Not fair ! You are comparing "4 CPUs and 15GB of memory" for NodeJS with "40 CPUs and 128 GB of memory" for Elixir/Phoenix

cpursley 7y ago
Ok, here's a better comparison: "Websocket Shootout: Clojure, C++, Elixir, Go, NodeJS, and Ruby" https://hashrocket.com/blog/posts/websocket-shootout https://hashrocket.com/blog/posts/websocket-shootout
- truth_seeker 7y ago
  > NodeJS performance is hampered by its single-threaded architecture, but given that fact it performs very well. The NodeJS server was the smallest overall in lines of code and extremely quick and easy to write. Javascript is the lingua franca for web development, so NodeJS is probably the easiest platform for which to hire or train developers. Do you actually read the blog post before making the claim ? The author is not using "Cluster" module to scale connections across CPUs with "Sticky-session" library. Also, neither he mentioned the runtime flags with which the launched all VMs in comparison nor he mentioned the optimization at OS level.
  - deorder 7y ago
    It seems that the author actually used the "cluster" module, but just does not mention it in the article: https://github.com/hashrocket/websocket-shootout/blob/master/js/run-cluster.js https://github.com/hashrocket/websocket-shootout/blob/master... I expected all benchmarks that use the (linux) kernel for I/O events would perform similarly. The code is so small that the interpreter overhead should not degrade the performance too much. May be the JSON parsing / serialization?
    - truth_seeker 7y ago
      So you think that "sticky-session" is not important ? Can you tell why ?
- jsd1982 7y ago
  That benchmark is from 2016, but the use of `golang.org/x/net/websocket` package for Go should be replaced with `github.com/gorilla/websocket` and re-run, if it hasn't been already. Based on their git repo, gorilla/websocket has existed in some form since at least 2013 though not sure how production-ready it would've been in 2016.
  - ptman 7y ago
    Or https://github.com/nhooyr/websocket https://github.com/nhooyr/websocket

cpursley 7y ago

Ok, here's a better comparison: "Websocket Shootout: Clojure, C++, Elixir, Go, NodeJS, and Ruby" https://hashrocket.com/blog/posts/websocket-shootout https://hashrocket.com/blog/posts/websocket-shootout

truth_seeker 7y ago
> NodeJS performance is hampered by its single-threaded architecture, but given that fact it performs very well. The NodeJS server was the smallest overall in lines of code and extremely quick and easy to write. Javascript is the lingua franca for web development, so NodeJS is probably the easiest platform for which to hire or train developers. Do you actually read the blog post before making the claim ? The author is not using "Cluster" module to scale connections across CPUs with "Sticky-session" library. Also, neither he mentioned the runtime flags with which the launched all VMs in comparison nor he mentioned the optimization at OS level.
- deorder 7y ago
  It seems that the author actually used the "cluster" module, but just does not mention it in the article: https://github.com/hashrocket/websocket-shootout/blob/master/js/run-cluster.js https://github.com/hashrocket/websocket-shootout/blob/master... I expected all benchmarks that use the (linux) kernel for I/O events would perform similarly. The code is so small that the interpreter overhead should not degrade the performance too much. May be the JSON parsing / serialization?
  - truth_seeker 7y ago
    So you think that "sticky-session" is not important ? Can you tell why ?
jsd1982 7y ago
That benchmark is from 2016, but the use of `golang.org/x/net/websocket` package for Go should be replaced with `github.com/gorilla/websocket` and re-run, if it hasn't been already. Based on their git repo, gorilla/websocket has existed in some form since at least 2013 though not sure how production-ready it would've been in 2016.
- ptman 7y ago
  Or https://github.com/nhooyr/websocket https://github.com/nhooyr/websocket