Subscribe
Sign in
Start new thread
WebsocketD
p/websocketd
WebSockets are easy now
Visit Product
Joe Walnes
WebsocketD — WebSockets are easy now
Featured
12
•
Replies
Joe Walnes
Maker
Yeah I shamelessly posted my own product. :) I think this will be useful as an alternative to hosted push services for those building web apps with streaming content (chatrooms, collaboraton, games, news feeds, stock tickers, etc). AMA
Greg Gilbert
Great tool and good job on the website! Looks clean and the tutorial is really clear.
Shamoon Siddiqui
Fast forward 5 years in a Serverless world: https://www.producthunt.com/post...
foo
Simple, unobtrusive and agnostic, love it :) I can see other uses than pure web, for that, by the way. For example, it would make it damn easy to plug arbitrary scripts to allow data to stream across some docker containers, without having to think of a tcp binded api.
Joe Walnes
Maker
Yeah! I often use websocketd as part of a larger toolkit for duct-taping things together. For example, combine websocketd and netcat/nc/socat to bridge existing TCP services to the web-browser via WebSockets $ websocketd --port 80 nc otherhost 1234 Some people do "websocketd bash" to create a remote console. But I really really don't recommend that unless you want to get totally p0wned.
Joshua Frattarola
This looks very useful. Any benchmarks you can share?
★ Karan Goel ☂
@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.
Joe Walnes
Maker
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!
Joe Walnes
Maker
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.
Joe Walnes
Maker
@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.
Joe Walnes
Maker
@mfkp Anyway, today is Chinese New Year and it's the year of 羊 (which means RAM)