>Avoid threading headaches >Each inbound WebSocket connection runs your program in a dedicated process. Not the best design decision
The quality of the design depends on the goals. For simplicity, seems like a great decision.
Websocketd
171–180 of 233 posts
Re: Websocketd
#172This is the second or third "it's CGI again" thing I've seen in the past year. While these things are cool and definitely have their place, it's still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it's probably unwise to deploy something like this in production anymore. It is what it is, I suppose.
While it's cute, I've never liked fork(). It's almost always followed by exec(), which means the default case is to do bookkeeping that is immediately discarded, something CoW helps with but doesn't eliminate (consider all those fds!)
Re: Websocketd
#173Earlier quoted context omitted.
SVR4 came out 30 years ago. I think it's time to let it go.
Aah the joys of false progressivism. I hear that representing the absence of value as a number was invented about 6000 years ago, perhaps we should abandon that as antiquated as well.. also, to wit, a Unix kernel of recent vintage: $ uname -msr OpenBSD 6.3 amd64 $ du -skc bsd.rd bsd 9664 bsd.rd 12912 bsd 22576 total vs, say, a Linux kernel of recent vintage: $ uname -msr Linux 4.9.0-8-amd64 x86_64 $ du -skc /boot/vml…
> yes, there are likely more drivers in the latter. highly doubt there is an order of magnitude more though.
That's exactly what they are; ~180M of those 212M are in drivers/. And even outside that, it includes stuff like fs/ocfs2, which I don't think OpenBSD supports.
Re: Websocketd
#174> Each inbound WebSocket connection runs your program in a dedicated process. Connections are isolated by process. I see you and 10,900 other "software developers" get the point of WebSocket. It's especially "impressive" when you written the whole thing in Go and could have used goroutines and channels, which could easily handle hundreds of thousand of connections (maybe millions). Terrible design! For a long time I…
There are definitely use cases for this, for instance you might have some command line application that uses standard io. Sure it might be adapted to have support for web sockets natively, but this of course takes time. And as the old adage goes time is money.
And sure you might be upset by "slow" websites, but for the small consultancy productising their scripts, it might make them - dare I say it, a quick buck. In the end the invisible hand of the market decides how much money is invested making websites fast and that is what guides the design of the technology being developed.
Perhaps it is you who fail to see the big picture.
Re: Websocketd
#175> Each inbound WebSocket connection runs your program in a dedicated process. Connections are isolated by process. I see you and 10,900 other "software developers" get the point of WebSocket. It's especially "impressive" when you written the whole thing in Go and could have used goroutines and channels, which could easily handle hundreds of thousand of connections (maybe millions). Terrible design! For a long time I…
The business logic is all outside of websocketd. There is no standard as to how to do this, so obviously the simplest way is to mimic CGI. Invocation happens when the status quo isn't enough, and the status quo until now was that there was no 10-second way to send whatever you want through websocket. It can happen now, and you can be the one to propose some better protocol for a websocket endpoint and a business logic process to discuss.
Re: Websocketd
#176Earlier quoted context omitted.
The myth that fork is expensive is pervasive, and speaking to the ways that it is true†, well: performance is relative. fork() only takes around 8ms on my Linux machine and I can get 100,000 posix_spawn() per second there with 100MB RSS. That's "fast enough" for a large number of applications. †: fork() is a lot slower (over 20x) on Windows
8ms per fork means you can only accept 125 connections per second. (per core) That means it's only viable for connections where the connection is very long lived and messages are very sparse (because context switches).
I think the real issue now is not how fast you can accept and process a new connection, but how many you can have in parallel. If you're going to have a native os process for each, you'll soon run out of resources
Re: Websocketd
#177Earlier quoted context omitted.
8ms per fork means you can only accept 125 connections per second. (per core) That means it's only viable for connections where the connection is very long lived and messages are very sparse (because context switches).
I was going to mention CPU context switching as well, it's very expensive even when you don't account for the initial fork overhead but I guess it's definitely a better idea than CGI for HTTP given the long lived connection. In an ideal scenario, you shouldn't have more active processes than you have CPU cores. As soon as that happens, context switching kicks in and performance degrades sharply.
Does this concern hold for containers per machine?
Re: Websocketd
#178Re: Websocketd
#179Earlier quoted context omitted.
If you’re using CGI or FCGI, then you’re using a general web server that is probably serving lots of different applications. These days, folks often write the app to contain a web server. Write your app in JavaScript, pull in a dependency that serves HTTP, write enough code to route requests and start the server listening- welcome to Node. Python and Ruby offer the same. Swift gets this functionality from Kitura and…
Yes but the poster, above, is complaining about using CGI with a server. My question is, if you're not using CGI/fastCGI with Apache or nginx for example, what is he suggesting should be used instead?
Using your language of choice: You open a socket on a port, listen for connections, when connection from client arrives read bytes from the socket, parse http request from those bytes, do something that may yield bytes in response, write the response bytes to the socket, close the socket (optional).
Re: Websocketd
#180Earlier quoted context omitted.
Aah the joys of false progressivism. I hear that representing the absence of value as a number was invented about 6000 years ago, perhaps we should abandon that as antiquated as well.. also, to wit, a Unix kernel of recent vintage: $ uname -msr OpenBSD 6.3 amd64 $ du -skc bsd.rd bsd 9664 bsd.rd 12912 bsd 22576 total vs, say, a Linux kernel of recent vintage: $ uname -msr Linux 4.9.0-8-amd64 x86_64 $ du -skc /boot/vml…
> yes, there are likely more drivers in the latter. highly doubt there is an order of magnitude more though. That's exactly what they are; ~180M of those 212M are in drivers/. And even outside that, it includes stuff like fs/ocfs2, which I don't think OpenBSD supports.
[deleted]