On Sat, 2008-02-02 at 20:38 +0000, Niall O'Reilly wrote: > On 2 Feb 2008, at 12:54, PAUL WILLIAMSON wrote: > > > >>> "Niall O'Reilly" <[EMAIL PROTECTED]> 2/2/2008 7:27 AM >>> > > > Would you care to explain how '3' has a scalability advantage > > > over ''1'? > > Because trying to maintain one file is a huge PITA. > > No doubt, but an earlier poster seemed to declare an > advantage due to scalability rather than to ease of > administration. This may be one aspect of scalability, > but it's surely not the only, or even most important, > one.
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. 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 of administration" is actually a critical scalability concern when you have large mrtg monitoring complexes. Running under linux, a large number of Includes: with forks: 20 is going to perform much better than twenty separate instances, as there is less parsing to do and more shared code. I know that is comparing "2" and "3", but again it continues to demonstrate a more scalable solution. > > I'm interested to know whether there's anything else > to the claim. > > /Niall > > _______________________________________________ > mrtg mailing list > [email protected] > https://lists.oetiker.ch/cgi-bin/listinfo/mrtg -- Daniel J McDonald, CCIE #2495, CISSP #78281, CNX Austin Energy http://www.austinenergy.com
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
