[Eventmachine-talk] eventable experiment and application-level

James Tucker
Wed, 13 Feb 2008 23:09:12 -0000

On 13 Feb 2008, at 22:02, Chuck Remes wrote:
>
>
> That looks pretty reasonable. I can use that as a guideline. Thanks!

welcome.

>
>
>> [snip]
>>
>> It''s possibly worth noting that there''s no
EventMachine code in
>> there.
>> You can easily wrap this up in deferrables and defer calls, make
>> event
>> processing queues, wrap short jobs in simple timer stacks for
>> ''lightly
>> deferred'' scheduling, etc. Keeping it real simple helps a lot.
>
> This is the rub right here. If I set a timer task to run very
> frequently, if there is no work to perform then this essentially
> devolves into polling. If I run the timer task once per second,
> pending events could wait a "long" time before being processed;
> throughput would suck.

Well if your desire was for a defer, then you could create a new one
any time a request comes in and there isn''t one running. If there is,
you can populate a queue (although, a non-blocking one, rather than
ruby''s thread Queue). I''ll be testing this structure with some
DB
drivers soon.

> I want to be able to post events to the reactor core and have it
> handle the dispatching for me. What would you recommend? If I''m
> missing something obvious or already answered, no need to be
> gentle. :-)

Well, passing it to the reactor loop is / would be essentially
identical to doing this:

Handlers[:event_name].each do |h|
	::EventMachine::add_timer(0, &h)
end

Only you wouldn''t really want to spam the timer map.

Incidentally, apart from that spam, it''s quite similar to doing all of
them in a single timer (invert the two blocks, basically).

As I said when I said keep it simple, start with the naive
implementation, no threads (defer), no deferrables, etc. Optimize if
you find you need to (mostly, you should not). Defer for example, is
unlikely to increase total performance significantly, unless the
contents of the call are going out to a high latency external
interface (like a blocking call, to say, a database).

Yes, it does start to resemble polling, only that''s exactly why the
drive for maintaining simplicity.

In fact, the best way to optimize in some of these situations, is to
implement two applications, and have one do nothing but take over high
latency jobs. The low latency ''client facing'' app is then free
to
continue processing client requests, maybe whilst waiting on
deferrable that close on responses from the high latency app. Other
useful features can then be added under this idea, like coalescing
messages, which can be used to rapidly overcome the extra overhead
added (again, for some or a lot of cases).

>
>
> cr
> _______________________________________________