3 ms·

Just spawn more processes. Great solution! /s

sublinear 3y ago
Would you rather scale with more containers? That's heavier. Properly written node apps are bound by I/O throughput. CPU and memory cost for additional processes is minimal, but latency is significantly decreased with a worker pool.
- jitl 3y ago
  > Properly written node apps are bound by I/O throughput Does that mean that node apps shouldn’t do any computation on data, just move bytes between a file and a network socket? If I need my program to think, I wrote it wrong or in the wrong language? I would rather have shared memory multithreading be a usable feature in my program’s runtime. SharedArrayBuffer exists but 98% of existing code uses objects and arrays so can’t be easily shared between processes without copying, and the cost of copying objects with structuredClone puts a huge optimization barrier in between most code and parallel processing.
  - sublinear 3y ago
    No, just write your javascript to do more I/O than compute. Apps should do app things not low level tasks that slow things down. If you need to compute something complicated, write it in a compiled language and make it a node module. Many popular npm libraries are exactly this.
    - nesarkvechnep 3y ago
      Or… don’t write Node at all? I’d choose Elixir over Node any day.
  - throwitaway1123 3y ago
    > Does that mean that node apps shouldn’t do any computation on data, just move bytes between a file and a network socket? If I need my program to think, I wrote it wrong or in the wrong language? This is a very uncharitable interpretation of Node's primary use case. I think it would be more accurate to say don't use Node if all of the following apply: - Your task is CPU bound rather than IO bound (e.g. you're not waiting to insert or retrieve data from the database). - Your task is highly parallel (some computations are sequential and linear). You can't use worker threads because: - You have too much data to bear the cost of message passing via the structured clone algorithm. - You can't share memory and avoid structured cloning because your data can't be represented using an array buffer. This is a far cry from the claim that Node can't handle problems that require "thinking". When you're on the JIT compiler's happy path Node can think pretty quickly actually. In practice, many high volume web servers are handling enough requests that there's more than enough jobs for each Node process to have exclusivity over its jobs, and you don't need to share work between processes. Each process or worker thread can be largely independent. Not every task is going to fall within those boundaries, but that's ok, Node doesn't have to fulfill every use case.
mort96 3y ago
I mean... yes

Would you rather scale with more containers? That's heavier. Properly written node apps are bound by I/O throughput. CPU and memory cost for additional processes is minimal, but latency is significantly decreased with a worker pool.

jitl 3y ago
> Properly written node apps are bound by I/O throughput Does that mean that node apps shouldn’t do any computation on data, just move bytes between a file and a network socket? If I need my program to think, I wrote it wrong or in the wrong language? I would rather have shared memory multithreading be a usable feature in my program’s runtime. SharedArrayBuffer exists but 98% of existing code uses objects and arrays so can’t be easily shared between processes without copying, and the cost of copying objects with structuredClone puts a huge optimization barrier in between most code and parallel processing.
- sublinear 3y ago
  No, just write your javascript to do more I/O than compute. Apps should do app things not low level tasks that slow things down. If you need to compute something complicated, write it in a compiled language and make it a node module. Many popular npm libraries are exactly this.
  - nesarkvechnep 3y ago
    Or… don’t write Node at all? I’d choose Elixir over Node any day.
- throwitaway1123 3y ago
  > Does that mean that node apps shouldn’t do any computation on data, just move bytes between a file and a network socket? If I need my program to think, I wrote it wrong or in the wrong language? This is a very uncharitable interpretation of Node's primary use case. I think it would be more accurate to say don't use Node if all of the following apply: - Your task is CPU bound rather than IO bound (e.g. you're not waiting to insert or retrieve data from the database). - Your task is highly parallel (some computations are sequential and linear). You can't use worker threads because: - You have too much data to bear the cost of message passing via the structured clone algorithm. - You can't share memory and avoid structured cloning because your data can't be represented using an array buffer. This is a far cry from the claim that Node can't handle problems that require "thinking". When you're on the JIT compiler's happy path Node can think pretty quickly actually. In practice, many high volume web servers are handling enough requests that there's more than enough jobs for each Node process to have exclusivity over its jobs, and you don't need to share work between processes. Each process or worker thread can be largely independent. Not every task is going to fall within those boundaries, but that's ok, Node doesn't have to fulfill every use case.

mort96 3y ago

I mean... yes