------art_4177_22021321.1146857110344
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Ok, let's see if I understand you. (I certainly hope we're not going into
inappropriate territory for this list with a discussion of a particular
system design!)

You have a lot of network servers (many different protocols) floating around
your network, and you want to periodically send client requests to each of
them and measure the response times. (And of course send you alerts when
they don't respond.)

One way to do this would be to tell EventMachine to kick off one request for
each of the monitored servers every minute (for example). That's a simple
matter of instantiating a bunch of objects. The objects send their requests,
then wait for the responses, and then possibly talk to some singleton or
database connection somewhere. The objects die off by themselves when the
protocol-conversation completes or they time out. EventMachine manages all
of this by calling methods in your objects whenever timers expire or you
send data on them or they receive data from the network. So the network
drivers are working away in the kernel while you're processing each request.
To start it off, you call EventMachine's #run method, and it does everything
else. If you want to do other work on Ruby threads while the event machine
runs, that's ok too. The system will be live and concurrent as long as it
doesn't take you an inordinate amount of time to process each response
(you're probably just timing them, so no problem).

I'm happy to help you out if you want to give it a shot. Send me a private
email so we don't pollute this list ;-)

On 5/5/06, Don Stocks <amillionhitpoints / yahoo.com> wrote:
>
> Excellent!  It sounds like EventMachine may do exactly what I'm needing.
> That's great news.  Looks like I'll need to dig into it.  Thanks!
>
> Yes, I will be monitoring the most common network services (HHTP/S,
> SMTP, POP3, DNS, IMAP, etc.) on remote systems.  I'll also want to track
> things like connect times and transaction response times  I haven't
> started coding the monitor classes yet, as I'm just now trying to
> formulate a design.  It sounds like you may have done some of the work
> for me!  If I understand it correctly, I should be able to build my
> monitor classes implementing your existing protocol handlers and create
> my own protocol handlers for those that don't exist.
>
> To your latency question:  I hope I understand your question correctly.
> I think most of the latency will come from the network.  For example, if
> there are four monitors that need to be run in the current 60 second
> window, then I need to run them simultaneously.  If they are run in
> serial then monitors later in the queue could get stuck behind a long
> running monitor.  The polling server (the system running the monitors)
> can't get stuck on a single monitor for an extended period of time since
> that would cause all work to stop.  How would EventMachine handle this
> without running each active monitor in it's own worker thread?
>
> One the issue of scaling: I would like to use a shared queue that would
> allow additional polling servers to be added for scaling out.  Any itial
> thoughts on how EventMachine can fit into this model?
>
> I hope I'm not getting in over my head!  It seems pretty complex for
> such a simple mind. ;)
>
> Thanks for all the help! - Don
>
> --
> Posted via http://www.ruby-forum.com/.
>
>

------art_4177_22021321.1146857110344--