WebsocketD

@jfrattarola I'd be interested in this too. Also, how efficient/performant is a new process for each connection? Seems like the overhead of switching context will not make it worthwhile.

I don't have any benchmarks. I would like to have an independent party test it for performance. One concern many users have when first encountering it is the overhead required to launch a new process per connection. In reality (I've been running this for nearly 2 years in production) I've not found it to be a problem so long as your underlying programs start reasonably quickly. The runtime profile of a typical WebSocket connection is very different to a typical HTTP request. HTTP servers are optimized for high volumes of short requests whereas WebSockets are typically much lower volumes but longer lived connections. Also, Linux has got really good at handling large numbers of concurrent processes in recent years. tl;dr - it's good!

I've been running this on a production server which peaked at just over 10K concurrent WebSocket connections and it's been fine. The biggest constraint is memory. My server had 256GB RAM and only 30% of that was used. Assuming your programs startup reasonably quickly and don't use too much memory, all is good. Typical Python and Ruby programs are fine. Anything involving the JVM is more problematic.

@joewalnes I'm hoping you meant 256MB!

@mfkp Nope - it was a beefy server. If you're planning on scaling 10K concurrent connections on 256MB, then admittedly websocketd is not for you and you should use a single process multi-threaded architecture. Node, Go, Rust, Elixir are all excellent choices.