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

Reply via email to