<story><title>Websocketd</title><url>http://websocketd.com/</url></story><parent_chain><item><author>geocar</author><text>The myth that fork is expensive is pervasive, and speaking to the ways that it is true†, well: performance is relative.&lt;p&gt;fork() only takes around 8ms on my Linux machine and I can get 100,000 posix_spawn() per second there with 100MB RSS.&lt;p&gt;That&amp;#x27;s &amp;quot;fast enough&amp;quot; for a large number of applications.&lt;p&gt;†: fork() is a lot slower (over 20x) on Windows</text></item><item><author>jchw</author><text>This is the second or third &amp;quot;it&amp;#x27;s CGI again&amp;quot; thing I&amp;#x27;ve seen in the past year. While these things are cool and definitely have their place, it&amp;#x27;s still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it&amp;#x27;s &lt;i&gt;probably&lt;/i&gt; unwise to deploy something like this in production anymore. It is what it is, I suppose.</text></item></parent_chain><comment><author>NathanKP</author><text>I see this argument all the time but its not the fork() that is the most expensive anymore, its the actual program initialization after the fork(). If your app is non trivial (lets say a websocket based chat server that needs to persist messages to a DB and use pubsub to sync them to other processes) it probably needs a connection to a database, a connection to a cache server like Redis or Memcached, etc, or perhaps a connection to some other backend service. Reinitializing these dependency connections from scratch in a new forked process for every single incoming websocket connection is expensive and slow.&lt;p&gt;On the other hand a Node.js or Go program can have a preestablished pool of keep alive connections to the backends already ready to go and reuse that connection pool for many hundreds or even thousands of concurrent websocket connections. You can approximate something like this with the fork() model by having a local daemon process that manages the connection pool and have your forked process talk to that local helper daemon when it needs a connection, but you are still going to pay a penalty for that compared with having a fully preestablished connection ready to use right there in the process already</text></comment>
<story><title>Websocketd</title><url>http://websocketd.com/</url></story><parent_chain><item><author>geocar</author><text>The myth that fork is expensive is pervasive, and speaking to the ways that it is true†, well: performance is relative.&lt;p&gt;fork() only takes around 8ms on my Linux machine and I can get 100,000 posix_spawn() per second there with 100MB RSS.&lt;p&gt;That&amp;#x27;s &amp;quot;fast enough&amp;quot; for a large number of applications.&lt;p&gt;†: fork() is a lot slower (over 20x) on Windows</text></item><item><author>jchw</author><text>This is the second or third &amp;quot;it&amp;#x27;s CGI again&amp;quot; thing I&amp;#x27;ve seen in the past year. While these things are cool and definitely have their place, it&amp;#x27;s still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it&amp;#x27;s &lt;i&gt;probably&lt;/i&gt; unwise to deploy something like this in production anymore. It is what it is, I suppose.</text></item></parent_chain><comment><author>mig_</author><text>The initial fork is fast because of the copy on write memory semantic. You&amp;#x27;ll pay a price later.</text></comment>