[rrd-users] Re: Perl and RRDTool

[Jason Frisvold]

Yes, that helps tons..  :)  Thanks a lot!

BTW...  what manual states that?  Is it in the RRDs doc?

---------------------------
Jason H. Frisvold
Senior ATM Engineer
Engineering Dept.
Penteledata
CCNA Certified - CSCO10151622
friz at corp.ptd.net
---------------------------
"Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former." -- Albert Einstein [1879-1955]


-----Original Message-----
From: Todd Caine [mailto:todd_caine at eli.net] 
Sent: Tuesday, October 02, 2001 11:10 AM
To: Jason Frisvold
Cc: 'Rrd-Users'
Subject: Re: [rrd-users] Perl and RRDTool

Hello Jason,

If you don't have any special reason why you need an independent RRDtool
process, then I would say always use RRDs from within your Perl scripts.
There
is no reason for the overhead of forking of another process.  The manual
states:

    If you have the choice use this interface (RRDs), as it is more
efficient
and gives you better access to data returned from the various functions of
RRDtool.

The only time I've used RRDp was to create an RRD Updater daemon which would
spawn off new process so that the daemon wouldn't block on update requests,
that
way I was able to still queue update requests until the RRD process was free
to
handle more requests.

Hope that helps a little.

Cheers,
Todd


Jason Frisvold wrote:

> Greetings,
>
>             I'm a bit new to RRDTool and I'm having a little trouble
> figuring out what I need to use...  I see 2 Perl Modules.  RRDp.pm and
> RRDs.pm.  From what I've read, RRDp is a piped version, and RRDs is a
shared
> version.  My problem is, I'm not sure what the advantage of one over the
> other is.  I'm inclined to use RRDs because it seems to be more robust for
> what I want to do...  Let me explain a bit further..
>
>             I have a huge database of equipment that we track (memory,
> octets, temperature, etc).  Right now I have a perl program building
several
> MRTG configs and firing up MRTG to collect the needed data.  MRTG is in
> rrdtool mode, so it's saving all that info into RRD's.  (This is until I
> have a chance to write a custom collector so I can combine info and do
other
> nifty things)  In another table in the database, I plan to store a listing
> of options for rrdtool.  This way I can have the type of graph displayed
> change based on user preference or on the type of data that I am storing.
> So, I need to get the options from a database and pass them to rrdtool.
>
>             I think RRDs is the way to go because it's not running rrdtool
> concurrently as it builds whatever data it needs to...  (I know I can
> start/stop at will, but it seems like more overhead to me)
>
>             Am I correct in my thinking here?  Can someone point me in the
> right direction, or at least point me to some good info on piped versus
> shared?
>
> Thanks,
>
> ---------------------------
> Jason H. Frisvold
> Senior ATM Engineer
> Engineering Dept.
> Penteledata
> CCNA Certified - CSCO10151622
> friz at corp.ptd.net
> ---------------------------
> "So Long and Thanks for all the Fish" -- Douglas Adams [1952-2001]
>
>
> --
> Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
> Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
> Archive     http://www.ee.ethz.ch/~slist/rrd-users
> WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

--
Todd Caine
Software Engineer
Electric Lightwave, Inc.
tcaine at eli.net
(360) 816-4344


--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi