Re:Show HN: A Unixy approach to WebSockets
by rapind on Monday February 16, 2015 @09:59AM
(#9057124)
FYI I built simple count and greeter versions in Nim and they used around 350k. Some napkin math theorizes that's over 10k concurrents on an 4GB VPS for say a simple chat service backed by redis. I'm not sure how well websocketd will hold up at that point though...
Per process could mean easier scaling too. Like round robin connections balanced between multiple app servers backed by a beefy shared redis for example. I've never really understood how best to scale websocket services, but this could make it easier.
Re:Show HN: A Unixy approach to WebSockets
by asergeyev on Monday February 16, 2015 @05:03PM
(#9059340)
Thanks for that experiment!
Re:Show HN: A Unixy approach to WebSockets
by danieldk on Sunday February 15, 2015 @04:08AM
(#9052120)
The problem here of course is that a CGI-like approach does a fork plus execve for each request, which does not give a large benefit of sharing.
If you have a simple forking socket-based server, Linux (I assume that OS X is not any different) the amount of memory per process is much lower because it uses copy-on-write pages for forks and it's largely the same process.
Re:Show HN: A Unixy approach to WebSockets
by leephillips on Saturday February 14, 2015 @09:45PM
(#9051613)
That must be an OSX oddity. I just checked my Ubuntu laptop with 3GB RAM: 23967 processes, and a Debian server that I happened to be logged in to, with 0.5 GB: 127118 processes.
There's also a limit to the number of processes allowed as well. On my OSX laptop with 16Gb RAM for example the default limit is 709 (kinda strange number???). The command
ulimit -a
will tell you the value of "max user processes" for your machine.