27 Mar 2012, 09:32
Zeno_surf_pragsmall

Zeno Davatz (4 posts)

Quote from the book, page 170

bq. If the number of clients increases to thousands or tens of thousands, then you may want to use other solutions, such as EventMachine.

I can add to that: The amount of clients can be hundreds but if the requests per client per second are dozens - come from some big GoogleSpider - then you will need a new process.

28 Mar 2012, 07:39
Generic-user-small

Makoto Inoue (9 posts)

Thank you for your comment again!!

I don’t think this is true. Thread will be problematic if number of concurrent connections is too high. I am assuming that “request per client per second” is synchronous/serialised requests and processing these won’t make any difference either Thread or EM.

I confirmed this with Seki san and here is his reply.

“What EM(“epoll” system call) resolves (compared to “select” system call) is overhead of memory copy in user land and kernel land. There is no difference in cost actually processing the request”

Hope this makes sense.

18 Apr 2012, 16:00
Generic-user-small

José A. S. Alegria (4 posts)

Hi! Is there any attempt to create an EventMachine ready asynchronous version of RINDA’s API (write, take, …)? Or at least a Fiber ready one?

Regards,

José Alegria

24 Apr 2012, 21:49
Generic-user-small

Makoto Inoue (9 posts)

Hi, Jose. I don’t know the EM based one, but here are some alternatives.

https://github.com/dambalah/blackboard is redis version of Rinda with async feature, though it has not been developed for more than a few years.

Another library you may want to check out is dcell (http://www.unlimitednovelty.com/2012/04/introducing-dcell-actor-based.html). It’s async distributed object, though interface is different from rinda.

Hope this helps

26 Apr 2012, 21:48
Generic-user-small

José A. S. Alegria (4 posts)

Thanks for your feedback!

Regards,

José Alegria

  You must be logged in to comment