[akshayrajp]

I am currently looking for ways to build a service that can handle around 100k-200k active concurrent websocket connections on production. It's wild seeing this article here. Does anyone know of any alternative ways to do this? Most people seem to suggest using Elixir but I wonder if I can achieve the same using a more "conventional" language such as Java or Golang.

This article covers Node.js for me, I guess.

[lawik]

Elixir is well suited to highly concurrent systems and work like this. I'm big on the whole Elixir ecosystem though so I haven't explored other options.

I don't see why there would be anything stopping Go from being similarly capable as it also has a good reputation for concurrency and what I hear does preemptive scheduling.

Java can probably do anything except be fun and lightweight so assuming you want to figure out the hoops to jump through. I assume it could..

Elixir can do it with the ergonomics and expressiveness of Python/Ruby. If you enjoy that level of abstraction I recommend it.

[a_c]

Do you have any pointer, book preferably, in starting an exploratory Elixir project? I don't have any objective apart from giving the ecosystem a taste

[szundi]

Java is slowly absorbing the ideas from other systems and is much more fun than it was.

Also versatile.

[inglor]

We did this with Node.js and uWebSockets and it scaled easily to a few million web sockets on ~10 machines so I can confirm the stack works in practice

[r1ch]

We used the C++ version of uWebSockets to replace a legacy node app. We went from four fully loaded cores to about 20% of a single core and a fraction of the memory usage. It's a great library.

[prox]

I am trying to imagine why one would need millions of web sockets :) What are the use cases here?

[tmikaeld]

Check out Centrifugal:

https://github.com/centrifugal/centrifugo (Server/Admin)

https://github.com/centrifugal/centrifuge (Server core)

https://github.com/centrifugal/centrifuge-js (Library)

It's a complete solution, including server, admin panel and client library.

[latch]

Honestly, what matters is (a) what you're going to be doing with those connections and (b) your hardware.

As a generalization (again, really depends what you're going to be doing), I'd expect people to get a lot further with a Go or Java based implementations. Specifically, if those connections are interacting with each other in any meaningful way, I think shared data is still too useful to pass up.

I've written a websocket server implementation in Zig(1) and Elixir(2)

(1) https://github.com/karlseguin/websocket.zig (2) https://github.com/karlseguin/exws

[newjersey]

> Specifically, if those connections are interacting with each other in any meaningful way, I think shared data is still too useful to pass up.

What does this mean? What are some scenarios where connections interact with each other? I work with dotnet. To me, every request is standalone and doesn’t need to know any other request exists. At the most, I can see doing some kind of caching where if someone does a GET /person/12345 and someone else does the same, I maybe able to do some caching. However, I don’t think this is what you meant by shared data.

Did you mean like if someone does a PUT /person/12345/email [e-mail] instead of the next get request reaching to the database, you keep it in the application memory and just use it?

Or am I completely missing the point and you’re talking about near real-time stuff like calls and screen sharing?

[winrid]

Pretty much any modern runtime (Java/Go/Node w/ native bindings) can handle that many connections per machine. You probably want to horizontally scale it with kafka or similar, but anyway, a single machine will work to start.

[pritambarhate]

With Netty and Java you can easily handle 100-200k active web socket connections on a single server.

It was being done 7-8 years ago. If you search you should find a few articles on this.

[winrid]

Considering someone had a 100k+ idle connections on a raspberry pi with Java/Netty, yeah, you could get to a million today with some mid tier hardware and Linux tuning, pretty easily.

[bob1029]

.NET7 and Kestrel are likely able to pull this off if properly configured. Kestrel/AspNetCore routinely shows up in the top 10 techempower web benchmarks.

[tester756]

I'm not trusting benchmarks that I didn't fake myself.

Anyway - there's a lot of "non-standard" stuff in ASP's code there.

[opendomain]

Can you please suggest a link to show how to do this?

[norman784]

Node might be faster to write, but harder to maintain in the long run, also is not as reliable as Go or Rust, I personally will pick Rust because I have experience with it, but AFAIK Go has a very good reputation, the only "difference" with Rust is the GC (I mean "difference", because Go performance is not that far off from Rust, and seems also easy to write in Go than in Rust).

Also IMHO it's better to have a strong typed language behind your project, if it will be big, dynamic languages and big projects tend to be a nightmare for me.

[okal]

Would you mind unpacking how, in your view, Go/Rust/compiled strongly-typed languages lead to more *reliable* software? I can see how performance and maintainability* are sort of self-evident arguments in favour of them, but not sure how reliability could be a feature inherent to a language/runtime.

* As a build/compile-time concern, using Node doesn't preclude strong-typing, so maintainability is also not a strong argument against the runtime itself, given you can use e.g. TypeScript.

[hknmtt]

Node is a joke. It's not good for this.

Check out https://github.com/panjf2000/gnet, it also has some links at the end.

[Sosh101]

Care to explain why node is "a joke"? It's often used for these kind of applications.