On Wed, 18 Jun 2003, Gary Richardson wrote:
> To save perl startup time, would it be worth while to add the ability to
> tell mon to fork and eval the application if it is a perl script?
i've thought about this in the past, and here's the idea i have:
have the option of two different types of monitors:
type "a": the existing type which are forked for every invocation. these
are easy to write so they have great utility for quick
site-specific customizations, but can be inefficient if you have
a huge and complicated mon configuration with many hundreds of
services. also, you can write these monitors sloppily and not
worry about memory leaks because their lifetime is very short.
type "b": these are started when the mon server initially starts (or
after a configuration reload or reset). they receive orders
from a connection to a local socket or some form of ipc. the
orders are "test this list of hosts and get me the results",
just like regular monitors, but the invocation and communication
mechanism is different. there is a "master" monitor which
accepts these connections and forks off a child to handle
each request. the child is the same program but a different
function, so no exec is done to load a new program. this is
somewhat similar to how apache handles http requests.
when mon schedules a test for a type "b" monitor, rather than
forking and execing, it simply makes an ipc connection to the
already-running monitor and delivers its orders, and waits for
the results.
this type of monitor is more complicated to write, but it can
scale much better than the fork-and-exec type of monitor. since
these are long-running processes, you need to worry about memory
leaks, but it could be possible to perodically restart these
monitors without causing a noticeable drop in performance. there
will likely be a very few number of these types of monitors.
sound reasonable?
_______________________________________________
mon mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/mon
