Great response Antoni. A fundamental understanding of the difference between threads and kqueue/epoll (which power NIO) should clear up anyone's misgivings about evented servers. They are clearly more scalable, it is no contest.
- Greg On Jul 8, 2010, at 5:26 PM, Antoni Batchelli wrote: > On Jul 7, 2010, at 8:47 PM, gary b <gary.b...@gmail.com> wrote: > >> This blog post presents data showing that threading is faster than >> NIO: >> http://mailinator.blogspot.com/2008/02/kill-myth-please-nio-is-not-faster-than.html >> > I would not consider this article to be the definitive answer to the > question of NIO vs threads. My experience with high throughput java > servers is NOT what this guys represents. You can push NIO very far if > you want to, although it is hard. The advantage with NIO is that your > code doesn't have to go through the many abstraction layers that make > things very easy for the developer but quickly get in your way if you > want raw performance. > > Also, in some instances with NIO you can even work directly with > kernel buffers, and so the network data doesn't even need to be copied > from the kernel space into the user space. That takes time if you are > managing a lot of network traffic. > > Finally, as it has already been discussed, threads use memory, lots of > it. If the number of threads is not bound, a traffic spike will make > your memory requirements skyrocket, either exhausting the memory in > your JVM or prompting the OS to start paging on its VM. In the second > case, once your server is hitting Virtual Memory all those threads > will cause page misses left and right, and you'll watch your server > grind to a halt, since it will not be returning responses but still > receiving requests and thus creating even more new threads, happily > marching into a death spiral. > > Even if that article is right, fast != scalable, or high throughput, or > bounded. > > Yes, I have issues with that article as I have seen it quoted one too > many times ;) > > >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en