4 ms·

> Does this mean that a web server written in node is running single-threaded? Yes. > But doesn't running on a single thread put an upper limit on the amount

by nitely 9y ago

> Does this mean that a web server written in node is running single-threaded? Yes. > But doesn't running on a single thread put an upper limit on the amount of work a server can handle? Is not about how much work it can handle, it's about how much it can offload. Async servers can handle a much greater volume of I/O bounded tasks. So it can handle more connections. When the task is CPU bounded you can either create a thread (which does not really scale well) or offload it to some other servers that can scale horizontally (i.e doing micro services) > And, if the solution is to spin up more servers with access to the same database, doesn't that mean that we are now having multiple threads accessing the database concurrently? Much like, say, Python Django? Yes, to take advantage of all CPU cores you have to create more server instances. But why would they talk to the same database instance? It could be a replica or a shard. You can even have a pool of shards connections per server instance.

amelius 9y ago
The problem with offloading to a thread is that you can't structurally share data with another thread. So any copying of e.g. arguments can be very expensive, and awkward/inconvenient as well.
- nitely 9y ago
  I agree. But like always, trade-offs. > The problem with offloading to a thread is that you can't structurally share data with another thread. That's really a JS issue, not a general async programming issue, though.
- fauigerzigerk 9y ago
  If the other thread/process is running on a different machine (or you want to keep that option open) that's what you're going to have to do anyway though.
  - amelius 9y ago
    Yes, but that's a big "if". Sometimes you want to use a thread to keep the CPU from blocking (e.g. long database operations). Also, sometimes you want to use the CPU to its full capabilities.
    - frutiger 9y ago
      Database access, likely the most common I/O operation from a web server, is certainly running in another process (or on another machine) - I'm not sure that "if" is as big as you suggest.
    - fauigerzigerk 9y ago
      >Sometimes you want to use a thread to keep the CPU from blocking (e.g. long database operations). On the contrary. That's the prototypical use case for non-blocking event based IO. No threads needed. >Also, sometimes you want to use the CPU to its full capabilities. You can use all CPUs by using multiple processes. That's not an issue. Threads are useful when you want to run multiple algorithms in parallel on the same bigish in-memory data structure, especially one that has a lot of pointers. Something like an in-memory graph database or a desktop application that lets you work with huge files in-memory, or even complex user interfaces. For instance, I'm not convinced that the cross process bridging that React Native has to do is a great idea. So yes there are use cases where threads are very beneficial. But on the server side it's essentially the database/analytics systems themselves, not the code that accesses them.
richmarr 9y ago
> > Does this mean that a web server written in node is running single-threaded? > Yes. Just to expand, this (like most things) is a simplification, as I'm sure nitely is just being too brief to explain. It's true for Hello World, and a little further, but real-world web servers in non-trivial contexts typically utilise techniques like clustering, workers, and other ways of delegating tasks to external processes.
coldtea 9y ago
>Yes, to take advantage of all CPU cores you have to create more server instances. But why would they talk to the same database instance? Why not? Unless you've exceeded the capacity of a single DB and have a real use for sharding etc, it would not make sense to have difference DBs (+ replication overhead) for different Node processes.
- nitely 9y ago
  The parent is asking how comes async I/O can handle higher volumes of requests given it's single threaded and even if it does how comes the database is still not the bottleneck. I answered both of these questions.
  - coldtea 9y ago
    Yes, and I had an objection with the answer to the second question, that it might leave the impression to the parent that sharding or replication and pooling is required to have good DB IO performance with multiple Node processes -- when in practice it might or might not be an issue. You can have a 12-processes node cluster and still not need a second db.

by nitely 9y ago

amelius 9y ago

The problem with offloading to a thread is that you can't structurally share data with another thread. So any copying of e.g. arguments can be very expensive, and awkward/inconvenient as well.

nitely 9y ago
I agree. But like always, trade-offs. > The problem with offloading to a thread is that you can't structurally share data with another thread. That's really a JS issue, not a general async programming issue, though.
fauigerzigerk 9y ago
If the other thread/process is running on a different machine (or you want to keep that option open) that's what you're going to have to do anyway though.
- amelius 9y ago
  Yes, but that's a big "if". Sometimes you want to use a thread to keep the CPU from blocking (e.g. long database operations). Also, sometimes you want to use the CPU to its full capabilities.
  - frutiger 9y ago
    Database access, likely the most common I/O operation from a web server, is certainly running in another process (or on another machine) - I'm not sure that "if" is as big as you suggest.
  - fauigerzigerk 9y ago
    >Sometimes you want to use a thread to keep the CPU from blocking (e.g. long database operations). On the contrary. That's the prototypical use case for non-blocking event based IO. No threads needed. >Also, sometimes you want to use the CPU to its full capabilities. You can use all CPUs by using multiple processes. That's not an issue. Threads are useful when you want to run multiple algorithms in parallel on the same bigish in-memory data structure, especially one that has a lot of pointers. Something like an in-memory graph database or a desktop application that lets you work with huge files in-memory, or even complex user interfaces. For instance, I'm not convinced that the cross process bridging that React Native has to do is a great idea. So yes there are use cases where threads are very beneficial. But on the server side it's essentially the database/analytics systems themselves, not the code that accesses them.

richmarr 9y ago

> > Does this mean that a web server written in node is running single-threaded? > Yes. Just to expand, this (like most things) is a simplification, as I'm sure nitely is just being too brief to explain. It's true for Hello World, and a little further, but real-world web servers in non-trivial contexts typically utilise techniques like clustering, workers, and other ways of delegating tasks to external processes.

coldtea 9y ago

>Yes, to take advantage of all CPU cores you have to create more server instances. But why would they talk to the same database instance? Why not? Unless you've exceeded the capacity of a single DB and have a real use for sharding etc, it would not make sense to have difference DBs (+ replication overhead) for different Node processes.

nitely 9y ago
The parent is asking how comes async I/O can handle higher volumes of requests given it's single threaded and even if it does how comes the database is still not the bottleneck. I answered both of these questions.
- coldtea 9y ago
  Yes, and I had an objection with the answer to the second question, that it might leave the impression to the parent that sharding or replication and pooling is required to have good DB IO performance with multiple Node processes -- when in practice it might or might not be an issue. You can have a 12-processes node cluster and still not need a second db.