[mtanski]

175 threads really don't use that much ram. I know userspace stacks are large by default but most apps don't use them and they are never materialized. So even if you're using 1MB of stack space for each one that's only 175MB. You can easily fit that on whatever is the smallest AWS instance.

I imagine that context switching between 175 OS threads all in the same process wouldn't really be that big of a deal.https://www.quora.com/How-does-thread-switching-differ-from-...

Additionally there are many legitimate cases for for a lot of threads like disk IO. If you find your self having to push a lot of bytes to/from a high iops drive like an SSD / NVM drive. Unless you're doing large sequential transfers that you can do in one large call, you will needs submit many concurrent request to saturate the drive (via threads). Disk IO is not network IO.

[fauigerzigerk]

To be honest, I don't really have a good intuition or hard data on where the context switching overhead (or other limits) starts to bite, because I have always avoided architectures that go into the hundereds or thousands of threads.

Maybe you are right and it's one of those urban myths that we sometimes carry over from times long past based on assumptions that are no longer true.

I would love to have more hard information on that one, because I think that the currently fashionable async/event based way of doing a lot of things makes programs much harder to understand and write.

[dboreham]

Good rule of thumb for modern kernel and server class hardware : 100's of (native) threads is ok. 1000's will probably be ok. 10's of 1000 is where you will start to see trouble and 100's of 1000 will most likely cause you to pull out your hair. So the comment above about 175 threads being too many is incorrect.