Dan,
Thank you very much for your reply. Some of this is information
which is new to me, or which I wasn't sure of. Other parts are
"old news", but still interesting.
Comments in line ...
On 4 Feb 2008, at 14:53, McDonald, Dan wrote:
an RRDtol front-end like routers2.cgi expects to find each router in a separate file. That makes it possible to display huge hierarchies of routers and sites. So, using separate files helps scale the display functions, making the overall system more scalable.
You seem to be saying that routers2.cgi treats "Include" as
an implicit configuration instruction for grouping or
partitioning the display. This is what I understood from
some reading, but I haven't yet had the opportunity to confirm
from experience.
Overloading "Include" in this way seems to me to introduce
undesirable brittleness. IMO, "Include" should simply make
a collection of configuration files appear as one large file,
and organization of the display should be determined by
explicit configuration directives.
If I had to run cfgmaker for all of my managed boxes at once, it would take close to an hour, but with my configurations segmented I can re-learn individual devices in just a few seconds. This "ease ofadministration" is actually a critical scalability concern when you havelarge mrtg monitoring complexes.
I understand. Since back whenever I first lost monitoring because
of a syntax error in specifying some hand-crafted new target, I've
always thought of this as a "basic survivability" issue rather than
in terms of "scalability". I see what you mean too.
Running under linux, a large number of Includes: with forks: 20 is going to perform much better than twenty separate instances, as there is lessparsing to do and more shared code. I know that is comparing "2" and "3", but again it continues to demonstrate a more scalable solution.
OTOH, the overhead you mention only occurs during startup, and
re-starting is less disruptive if only a single instance,
without "Include", has to be interrupted.
I'm wondering whether your idea that a single generously-included
and well-forked instance will perfom better than an equivalent
collection of include-free instances is based on a
"high-quality educated guess" (not to be discounted), or rather
on measurements. Has anyone done a study and published the results?
Best regards,
Niall O'Reilly
University College Dublin IT Services
PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
