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
> >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
More information about the rainbows-talk