On Wed, Jul 7, 2010 at 11:15 AM, Zach Tellman wrote:
> At the Bay Area user group meeting in June, there was a very
> interesting discussion about how to best use Clojure's concurrency
> primitives to field large numbers of concurrent requests, especially
> in a long-poll/push type application. W
> Maybe what I said makes less sense in the case of NIO vs blocking with
> threads - I've mainly been working with Intel Threading Building Blocks
> lately, where the cost of cache cooling is very real. For that reason (and
> the others mentioned - context switches and lock preemption), Intel
> Thr
On Fri, Jul 9, 2010 at 9:44 AM, Anders Rune Jensen <
anders.rune.jen...@gmail.com> wrote:
> On Fri, Jul 9, 2010 at 3:09 PM, David Nolen
> wrote:
> > On Fri, Jul 9, 2010 at 8:44 AM, Anders Rune Jensen
> > wrote:
> >>
> >> Very interesting!
> >>
> >> I've been following the thread with great inter
On 9 July 2010 14:09, David Nolen wrote:
> I'm curious how you ran that test. With ab running 10 clients for 1 second I
> see ~4000-5000 req/s using Compojure 0.4.0. With aleph I see ~8000-9000
> req/s. I also had a quick chat with Zach Tellman and it sounds like he
> hasn't done much in the way o
On Fri, Jul 9, 2010 at 3:09 PM, David Nolen wrote:
> On Fri, Jul 9, 2010 at 8:44 AM, Anders Rune Jensen
> wrote:
>>
>> Very interesting!
>>
>> I've been following the thread with great interest and did a quick
>> performance test today comparing standard compojure with jetty against
>> aleph and
Maybe what I said makes less sense in the case of NIO vs blocking with
threads - I've mainly been working with Intel Threading Building Blocks
lately, where the cost of cache cooling is very real. For that reason (and
the others mentioned - context switches and lock preemption), Intel
Threading Bui
On Jul 8, 2:26 pm, Antoni Batchelli wrote:
> 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.
I assume that you are referring to NIO direct byte buffers. A
thread
On Fri, Jul 9, 2010 at 8:44 AM, Anders Rune Jensen <
anders.rune.jen...@gmail.com> wrote:
> Very interesting!
>
> I've been following the thread with great interest and did a quick
> performance test today comparing standard compojure with jetty against
> aleph and netty. I get around 4500 req/s w
On Wed, Jul 7, 2010 at 11:15 AM, Zach Tellman wrote:
> At the Bay Area user group meeting in June, there was a very
> interesting discussion about how to best use Clojure's concurrency
> primitives to field large numbers of concurrent requests, especially
> in a long-poll/push type application. W
Whoops. s/Raoul/Peter Schuller/.
On Jul 8, 2010, at 7:03 PM, Greg wrote:
> I hope it didn't sound like I was saying threads are *always* bad, as I
> definitely don't think that. :-p
>
> Your link to the epoll + threads document is probably the best way to go
> (that I'm aware of), to address
I hope it didn't sound like I was saying threads are *always* bad, as I
definitely don't think that. :-p
Your link to the epoll + threads document is probably the best way to go (that
I'm aware of), to address any of the issues that Raoul brought up w.r.t. long
operations in between the events
Interesting link!
Unfortunately the link to the PDF was broken, here's one that works:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101.7987&rep=rep1&type=pdf
On Jul 8, 2010, at 6:48 PM, Raoul Duke wrote:
> can't we all just get along?
>
> http://lambda-the-ultimate.org/node/1435
>
On Thu, Jul 8, 2010 at 2:36 PM, Greg wrote:
> 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.
oh Erlang, were art thou?
--
You rece
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
can't we all just get along?
http://lambda-the-ultimate.org/node/1435
--
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 wit
> Under heavy load, this can be quite costly, especially if each request
> requires non-trivial processing (ie, enough to make time-slicing kick
> in).
This doesn't really jive with reality as far as I can tell; if
anything it is the exact opposite of reality. If you're doing
significant work in b
On Jul 7, 2010, at 8:47 PM, gary b 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 th
thank you!
On Thu, Jul 8, 2010 at 3:09 PM, David Nolen wrote:
> On Thu, Jul 8, 2010 at 3:02 PM, Wilson MacGyver wrote:
>>
>> for the hello world test, you are using the helloworld from
>> front page of node.js at http://nodejs.org/
>> right?
>>
>> how did you setup the clojure one?
>>
>> was it
On Thu, Jul 8, 2010 at 12:55 PM, Miki wrote:
> Hello David,
>
> > while aleph (via Netty) is easily getting 600-700 rq/s
> > even if I'm writing to a database (CouchDB).
> Can you share the code for this?
>
> All the best,
> --
> Miki
>
I don't have a standalone example at the moment. I might tr
On Thu, Jul 8, 2010 at 3:02 PM, Wilson MacGyver wrote:
> for the hello world test, you are using the helloworld from
> front page of node.js at http://nodejs.org/
> right?
>
> how did you setup the clojure one?
>
> was it what you posted before?
>
I wrote a blog post about it here with the code
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 c
for the hello world test, you are using the helloworld from
front page of node.js at http://nodejs.org/
right?
how did you setup the clojure one?
was it what you posted before?
(defn hello-world [request]
(future
(Thread/sleep 1)
(respond! request
{:status 200
Hello David,
> while aleph (via Netty) is easily getting 600-700 rq/s
> even if I'm writing to a database (CouchDB).
Can you share the code for this?
All the best,
--
Miki
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send e
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 significa
"well I think the main advantage" is memory. :-)
Theoretically (I think), thread-per-connection servers can be very close to
matching asynchronous servers in throughput, but they definitely require much
more RAM to do so. RAM is one of the more expensive commodities to come by on
VPS and cloud
On Wed, Jul 7, 2010 at 2:10 PM, James Reeves wrote:
> The main advantage of a non-blocking server is that you're don't use
> up a thread waiting for an event (such as the user sending data, or
> some other external trigger).
>
> - James
I think the main advantage of a non-blocking server is thro
On Wed, Jul 7, 2010 at 3:10 PM, James Reeves wrote:
> On 7 July 2010 19:04, David Nolen wrote:
>> So something like this:
>> (defn hello-world [request]
>> (future
>> (Thread/sleep 1)
>> (respond! request
>> {:status 200
>> :headers {"Content-Type" "text/html"}
On Jul 7, 11:17 am, David Nolen wrote:
> On Wed, Jul 7, 2010 at 2:10 PM, James Reeves wrote:
>
>
>
>
>
> > On 7 July 2010 19:04, David Nolen wrote:
> > > So something like this:
> > > (defn hello-world [request]
> > > (future
> > > (Thread/sleep 1)
> > > (respond! request
> > >
On Wed, Jul 7, 2010 at 2:10 PM, James Reeves wrote:
> On 7 July 2010 19:04, David Nolen wrote:
> > So something like this:
> > (defn hello-world [request]
> > (future
> >(Thread/sleep 1)
> >(respond! request
> > {:status 200
> > :headers {"Content-Type" "text/
On 7 July 2010 19:04, David Nolen wrote:
> So something like this:
> (defn hello-world [request]
> (future
> (Thread/sleep 1)
> (respond! request
> {:status 200
> :headers {"Content-Type" "text/html"}
> :body "Hello world!"})))
> Is non-blocking and
On Wed, Jul 7, 2010 at 1:43 PM, Zach Tellman wrote:
> Developers are still required to "participate" in the NIO design, in
> that blocking calls in the request handler need to be avoided to reap
> the full benefits. Netty provides a lot of nice abstractions over
> NIO, but kind of punts on how t
On Jul 7, 8:28 am, ngocdaothanh wrote:
> > For some reason I couldn't get 3.2.1.Final to come in via maven.
>
> I think you need to add this to project.clj:
> :repositories [["jboss" "http://repository.jboss.org/nexus/content/
> groups/public/"]]
>
Thanks, I'll give that a try.
> > What qualitie
On Jul 7, 9:12 am, David Nolen wrote:
> On Wed, Jul 7, 2010 at 5:15 AM, Zach Tellman wrote:
> > With this in mind, I decided to make the thinnest possible wrapper
> > around Netty such that a person could play around with alternate ways
> > to use Clojure effectively. The result can be found at
> For some reason I couldn't get 3.2.1.Final to come in via maven.
I think you need to add this to project.clj:
:repositories [["jboss" "http://repository.jboss.org/nexus/content/
groups/public/"]]
> What qualities is it missing that make the bang misleading?
I thinks ! means something dangerous
On Wed, Jul 7, 2010 at 5:15 AM, Zach Tellman wrote:
> With this in mind, I decided to make the thinnest possible wrapper
> around Netty such that a person could play around with alternate ways
> to use Clojure effectively. The result can be found at
> http://github.com/ztellman/aleph.
I played
On Jul 7, 2:57 am, ngocdaothanh wrote:
> > [org.jboss.netty/netty "3.2.0.BETA1"]
>
> Netty 3.2.1.Final has been released.
>
> I think the ! mark in "respond!" is kind of misleading. Why not change
> it to "arespond"?
For some reason I couldn't get 3.2.1.Final to come in via maven. I
didn't want
> [org.jboss.netty/netty "3.2.0.BETA1"]
Netty 3.2.1.Final has been released.
I think the ! mark in "respond!" is kind of misleading. Why not change
it to "arespond"?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email t
On Wed, Jul 7, 2010 at 5:15 AM, Zach Tellman wrote:
> At the Bay Area user group meeting in June, there was a very
> interesting discussion about how to best use Clojure's concurrency
> primitives to field large numbers of concurrent requests, especially
> in a long-poll/push type application. W
At the Bay Area user group meeting in June, there was a very
interesting discussion about how to best use Clojure's concurrency
primitives to field large numbers of concurrent requests, especially
in a long-poll/push type application. We didn't arrive at any solid
conclusion, but it was clear to e
39 matches
Mail list logo
