search

joewalnes / websocketd

Turn any program that uses STDIN/STDOUT into a WebSocket server. Like inetd, but for WebSockets.
http://websocketd.com/
BSD 2-Clause "Simplified" License
17.17k stars 1.02k forks source link

webSocketd not production-ready? #226

Closed jonmalave closed 8 years ago

jonmalave commented 8 years ago

I came across a review of websocketd here: http://theburningmonk.com/2014/01/echo-websocket-server-using-websocketd-as-if-by-magic/ one critical issue this review pointed out is that websocketd will spawn a new instance of your websocket app for every new connection. If that is the case, then that would mean websocketd is not a good solution for production apps.

I was considering websocketd over a hosted websocket service like Pusher, but now i'm not so sure. Please advise.

joewalnes commented 8 years ago

Spawn a new instance for each connection: true

Therefore not production ready: I would disagree. This is a deliberate design decision of websocketd that in many ways simplifies production. Isolate processes ensure memory containment, allow bad actor connections to be isolated / niced / killed. It puts more of the responsibility back on the operating system, and (most) OSs are good at this!

However it really depends on your runtime model. If your handlers are heavy / slow to start, it's not always ideal. Also if you have a system where you expect to have high volume of short lived connections, something that doesn't spawn may be advantageous.

However, the nature of the kind of WebSocket systems I typically deal with tend to have 1000s of concurrent long lived connections to lightweight handlers, which is an ideal fit for websocketd.

joewalnes commented 8 years ago

Spawn a new instance for each connection: true

Therefore not production ready: I would disagree. This is a deliberate design decision of websocketd that in many ways simplifies production. Isolate processes ensure memory containment, allow bad actor connections to be isolated / niced / killed. It puts more of the responsibility back on the operating system, and (most) OSs are good at this!

However it really depends on your runtime model. If your handlers are heavy / slow to start, it's not always ideal. Also if you have a system where you expect to have high volume of short lived connections, something that doesn't spawn may be advantageous.

However, the nature of the kind of WebSocket systems I typically deal with tend to have 1000s of concurrent long lived connections to lightweight handlers, which is an ideal fit for websocketd.

jonmalave commented 8 years ago

@joewalnes thanks so much for the quick reply. It's very helpful information that should help me make the best decision for my future websocket apps. Currently I am just experimenting with different Websocket server options. Again much appreciated, thank you!

asergeyev commented 8 years ago

Modern machines easily spawn thousands of child processes in a second. So if you really expect that websocket app would have more than 10,000 clients using it, I'd avoid websocketd. But it's really small number of apps that need that, usually clients come and go and having 2-server setup that can handle 10-20K active users is probably as much as 90% of people need.

As Joe said, you'd have troubles reaching this kind of numbers with heavy applications behind websocketd. When each of them requires lots of resources you probably will quickly get into double digits of apps per server.

aj664 commented 8 years ago

so you're saying it's not webscale ;)

yeah.. computers run as fast as the slowest component.. everything waits at the same speed! you'll run out of other resources before you really run out of websockets.

On 15/09/2016 10:07 PM, Alex Sergeyev wrote:

Modern machines easily spawn thousands of child processes in a second. So if you really expect that websocket app would have more than 10,000 clients using it, I'd avoid websocketd. But it's really small number of apps that need that, usually clients come and go and having 2-server setup that can handle 10-20K active users is probably as much as 90% of people need.

As Joe said, you'd have troubles reaching this kind of numbers with heavy applications behind websocketd. When each of them requires lots of resources you probably will quickly get into double digits of apps per server.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/joewalnes/websocketd/issues/226#issuecomment-247310120, or mute the thread https://github.com/notifications/unsubscribe-auth/AKg7wWOBr612RhB_49bUPkkGgM9QxS4iks5qqTTmgaJpZM4J9Tr4.

jonmalave commented 8 years ago

good points @asergeyev @aj664 thanks for your input!

I have to add that I was successfully able to setup Pusher in a matter of minutes, and was able to convert an AJAX/PHP based chat app to AJAX/Websocket chat app in minutes as-well. While I was struggling trying to just get Websocketd to run for a whole day. I don't mean to share that to try and bash Websocketd, just sharing my experience thus far. As I find Websocketd as a possible alternative to Pusher, but so far Pusher is winning in my book from a usability perspective.

Besides previously not being able to run Websocketd on my Ubuntu 14.04 server (#227 resolved). I was also digging through the FAQ and found an unanswered question about 'dirty' disconnects. https://github.com/joewalnes/websocketd/wiki/FAQ. (see bottom of page) 17 Minutes is a long time to wait for a disconnect to happen from in-activity. Any updates on this?

And finally while we are on the topic, does anyone mind doing a comparison between Websocketd and Pusher? I'm curious of the real advantages, disadvantages between the two. As these are the ones i'm considering to use out of all other Websocket solutions I have come across.