From: Francis Cianfrocca Date: 2006-05-06T02:35:26+09:00 Subject: Re: Big Work Loads & Concurrency ------=_Part_2534_31269188.1146850523493 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The idea behind using a single-threaded engine ("reactor model") in your application would be this: Each of your tasks is implemented in nothing mor= e than a instance of a Ruby class (that you write). Rather than asking you to maintain a thread pool and schedule each chunk of work onto the next available thread, EventMachine just calls methods on your objects whenever it's time to do some work. It definitely does have the ability to fire requests into your objects periodically, based on timers that you set up. The reason to use this approach instead of thread pools is that it can be far faster and more scalable. The downside is that your network-protocol handling may be a little more complicated. Since you're talking about monitoring a large number of external entities (processes? systems? users?), my next question is: what network protocol will be used? We've already implemented EventMachine protocol handlers for HTTP/S, LDAP, SMTP, SIP, and a few others. On 5/5/06, Don Stocks wrote: > > Francis, > > I took a look at EventMachine. It looks very intersting. But it seems > that it's primary use is to abstract networking. What are your thoughts > on how this could be leveraged for use in the monitoring service I > describe above (i.e. manage a large, dynamic queue of jobs and run them > at specific intervals). > > Thanks! - Don > > Francis Cianfrocca wrote: > > Depending on what you're trying to do, a single-threaded approach may > > give > > you more scalability and performance: > > http://rubyforge.org/projects/eventmachine > > > -- > Posted via http://www.ruby-forum.com/. > > ------=_Part_2534_31269188.1146850523493--