There are more rasons to want to avoid using threads than memory. Besides the obvious cost of creating and destroying threads (which is reduced or removed by using thread pools), you also have the cost of time slicing once you have more software threads than hardware threads: there is the obvious cost of context switching, but also less obvious costs such as bad processor cache usage (cache cooling, false sharing etc) and lock preemption (if the threads make use of shared resources). Under heavy load, this can be quite costly, especially if each request requires non-trivial processing (ie, enough to make time-slicing kick in).
So, between memory overheads, cost of creating and destroying threads and context switching, using a synchronous model can be extremely heavyweight compared to an asynchronous model. Its no surprise that people are seeing much better throughput with asynchronous servers. On Jul 8, 4:47 am, gary b <gary.b...@gmail.com> wrote: > re: memory use > > If the number of concurrent requests is small, then the memory used by > thread per request is usually not an issue. > > When implementing long polling, the number of concurrent requests can > be very large. Sharing threads between requests in a long polling > server can result in significant memory savings. > > re: advantages of evented servers > > There are also disadvantages to an evented server. Writing logic in a > series of callbacks is more difficult to understand and debug than the > sequential code used in a thread per request model. > > re: throughput of Netty/Aleph vs. Jetty > > The difference in throughput between Aleph/Netty and Jetty might not > be a result of the different threading models. It might be that Jetty > has more goop in it than Netty (I don't know if this is true or not). > This blog post presents data showing that threading is faster than > NIO:http://mailinator.blogspot.com/2008/02/kill-myth-please-nio-is-not-fa... -- 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
