c10k paradigm

Eric Wong normalperson at yhbt.net
Tue Apr 16 17:24:17 UTC 2013


Alexandre Riveira <alexandre at objectdata.com.br> wrote:
> Em 15-04-2013 19:34, Eric Wong escreveu:
> >Yes, you would use EventMachine.threadpool_size = 50, though, with
> >Rainbows::EventMachine::TryDefer
> >
> >http://rainbows.rubyforge.org/Rainbows/EventMachine/TryDefer.html
> >
> >I forgot about this, not sure if it's used much, but "app.deferred?" is
> >an ad-hoc extension which Thin also supports
> 
> * EventMachine (less memory and cpu usage)
> I did a test  using a  core  with  ab-n  3000-c  1000
> http://127.0.0.1:3000/manager and  rainbows  with 3  workers,
> EventMachine  then 25%  cpu free while  XEpollThreadPool  left only
> 5%  free.

With Matz Ruby, XEpollThreadPool is only a win if much of your
code/extensions releases the GVL (or if you don't feel like porting
your code to take advantage of EM).

> *EventMachine.threadpool_size = 50
> I found  this code  and run  perfectly.  But  he has  a kind of lock
> slowness  as if using  XEpollThreadPool  but memory consumption  was
> lower.  Wonder  you can put  some  of the  rails Controllers  work
> by  EventMachine  without using  threads  while others  controlles
> using  threads.  Explain  the need.

"lock slowness" - which version of Ruby is this?

Did you modify your app to use app.deferred? + TryDefer as I pointed
you to in the other message?

> Could it be that  the controllers  of the  rails  would run without
> party  pool  threads  only with  EventMachine  (C10K) while others
> would use the  controller  with  EventMachine thread pool  (erp)?

That should allow some rails controllers to use threads
(app.deferred? => true) while others do not use threads
(app.deferred? => false).  Keep in mind this is not a very common
configuration, so not many people have experience with it in
production.


More information about the rainbows-talk mailing list