3 ms·

I did not see the specs for the systems used to perform the test, If they where using a multicore server, this would surly slant the results in favor of the thr

by kls 16y ago

I did not see the specs for the systems used to perform the test, If they where using a multicore server, this would surly slant the results in favor of the threaded model. As well, the JVM / Java was designed from the first release as a blocking IO style development language so you have years of development towards that design philosophy. I just don't see how apples to apples, on a single core, blocking can be faster than NIO. I think C would be a better testing ground, where you don't have built up layers over the years that reinforce one over the other.

dkarl 16y ago
If they where using a multicore server Where would they find a single-core server these days?
- sriramk 16y ago
  In the cloud. A lot of apps run on single core VMs
- frio 16y ago
  Typically, in the non-blocking IO space, you take advantage of the multiple cores by running multiple instances of your server. For instance, I run 4 Tornado instances on my quad-core server, sitting behind a simple nginx proxy (this is, of course, Python rather than Java). Admittedly, I haven't performed any benchmarks (I chose Tornado for reasons other than performance), but as with the OP, I was hoping the author of the article would provide more detail on their benchmark setup.
tbrownaw 16y ago
> I just don't see how apples to apples, on a single core, blocking can be faster than NIO. Well, select() and poll() both require scanning all watched fd's, so I could definitely see them being slow. Then if NIO is built on one of them, it would inherit that slowness. epoll doesn't need to be slow, so I'm not entirely sure what's going on there. Maybe it's only servicing one or two fd's per epoll_wait()? Maybe it has to do extra work to match an event to a Java object? Maybe queuing events for the next epoll_wait() is for some bizarre reason slower than switching threads (which I imagine is a lot lighter than a full context switch to another process)? > I think C would be a better testing ground, where you don't have built up layers over the years that reinforce one over the other. That depends on whether you're trying to benchmark the kernel or trying to figure out what will make your particular server (presumably written in Java in this case) run faster.

by kls 16y ago

dkarl 16y ago

If they where using a multicore server Where would they find a single-core server these days?

sriramk 16y ago
In the cloud. A lot of apps run on single core VMs
frio 16y ago
Typically, in the non-blocking IO space, you take advantage of the multiple cores by running multiple instances of your server. For instance, I run 4 Tornado instances on my quad-core server, sitting behind a simple nginx proxy (this is, of course, Python rather than Java). Admittedly, I haven't performed any benchmarks (I chose Tornado for reasons other than performance), but as with the OP, I was hoping the author of the article would provide more detail on their benchmark setup.

tbrownaw 16y ago

> I just don't see how apples to apples, on a single core, blocking can be faster than NIO. Well, select() and poll() both require scanning all watched fd's, so I could definitely see them being slow. Then if NIO is built on one of them, it would inherit that slowness. epoll doesn't need to be slow, so I'm not entirely sure what's going on there. Maybe it's only servicing one or two fd's per epoll_wait()? Maybe it has to do extra work to match an event to a Java object? Maybe queuing events for the next epoll_wait() is for some bizarre reason slower than switching threads (which I imagine is a lot lighter than a full context switch to another process)? > I think C would be a better testing ground, where you don't have built up layers over the years that reinforce one over the other. That depends on whether you're trying to benchmark the kernel or trying to figure out what will make your particular server (presumably written in Java in this case) run faster.