4 ms·

> The blocking model limits parallelism, horizontal scalability, and the number of concurrent push connections. [citation needed] Seriously, where are the ben

> The blocking model limits parallelism, horizontal scalability, and the number of concurrent push connections. [citation needed] Seriously, where are the benchmarks? I see lots of claims of threads being slow and heavy (see also every time green threads comes up), yet... they are not. And every benchmark I've seen shows that, gasp, kernals are really fucking good. And library-of-the-week's greenthread kernel is not. The author then says you should use NIO. But, well, NIO is slower than blocking IO. A lot slower: http://www.mailinator.com/tymaPaulMultithreaded.pdf http://www.mailinator.com/tymaPaulMultithreaded.pdf So if you're using NIO instead of blocking IO threads, well, say goodbye to 25-30% of your throughput. But at least you got to feel all clever using unnecessarily complex async programming, so that's worth it, right?

jlward4th 12y ago
It definitely depends on what your needs are. There are tradeoffs on both sides.
- crypto5 12y ago
  But for most of the typical web apps, non-blocking/reactive/etc programming is absolutely unnecessary.
sehugg 12y ago
Each thread has a minimum stack size which can grow memory quickly if you're using 10k's of threads. Using an async framework like Netty gets you into 100k connections and beyond. (Not that it's always the right thing to do unless you have lots of long-lived requests)
- kllrnohj 12y ago
  Like all virtual memory the stack isn't actually allocated until it's used. So, no, that doesn't grow memory quickly. And while it's great Netty will get you to 100k connections, you can totally have 100k real threads on Linux. In fact, as far back as 2.5 in 2003 starting & stopping 100,000 concurrent threads took just 2 seconds with the introduction of NPTL. CPUs & memory have gotten a smidge faster since the Pentium 4 days so that time has almost certainly dropped significantly.
  - sehugg 12y ago
    But the stack will be used for each request, especially in Java app servers where stacks are often dozens of frames deep. The lowest stack size I could get away with for Tomcat 6/JDK 1.6 was 128 KB. Sure, you could do better with a lightweight C/C++ solution.

jlward4th 12y ago

It definitely depends on what your needs are. There are tradeoffs on both sides.

crypto5 12y ago
But for most of the typical web apps, non-blocking/reactive/etc programming is absolutely unnecessary.

sehugg 12y ago

Each thread has a minimum stack size which can grow memory quickly if you're using 10k's of threads. Using an async framework like Netty gets you into 100k connections and beyond. (Not that it's always the right thing to do unless you have lots of long-lived requests)

kllrnohj 12y ago
Like all virtual memory the stack isn't actually allocated until it's used. So, no, that doesn't grow memory quickly. And while it's great Netty will get you to 100k connections, you can totally have 100k real threads on Linux. In fact, as far back as 2.5 in 2003 starting & stopping 100,000 concurrent threads took just 2 seconds with the introduction of NPTL. CPUs & memory have gotten a smidge faster since the Pentium 4 days so that time has almost certainly dropped significantly.
- sehugg 12y ago
  But the stack will be used for each request, especially in Java app servers where stacks are often dozens of frames deep. The lowest stack size I could get away with for Tomcat 6/JDK 1.6 was 128 KB. Sure, you could do better with a lightweight C/C++ solution.