[Top] [All Lists]

Re: Ruleset Performance Question

To: nv-l@lists.tivoli.com
Subject: Re: Ruleset Performance Question
From: James_Shanks@tivoli.com
Date: Mon, 2 Apr 2001 15:47:58 -0400
I don't have any easy answers for you.  There is no magic trade-off between
"great performance" and "easy to administer".  Generally speaking, the more
work you put in administering the thing, the better the performance.

Whether you have on large ruleset or many small ones may not make a
difference.  If the first thing is each one is some easy test, like event
attribute or trap setting, so that nvcorrd can determine quickly whether to
cease or continue, then it may not make a difference.  Remember that
nvcorrd is single-threaded, so he has to make all the comparisons same
whether you code them in one ruleset or two.

The performance bottle neck will come from querying the smartsets, so you
want to do that as little as possible.  nvcorrd has to wait on nvcold,
which has to wait on ovwdb, to get an answer for each query.  And there is
no way to speed it up.  Each query is unique.  It doesn't matter if you
just asked whether node xxx is a member of yyy a half-second ago or not.
nvcorrd doesn't "remember" what he just asked, he asks again, and nvcold
and ovwdb get the answer again.  But sooner or later you have to query he
smartset.  The only thing you could try if things seem slow is combining
smartsets into a superset  -- you can create a smartset made of two smaller
ones for example.

But until you try it, I don't think you can estimate what the performance
will be in your network.
That's what nvcdebug -d <all> will show you --  you can use that to turn on
the trace and follow the timestamps to see how long it take to process each
trap as it flows through.

James Shanks
Team Leader, Level 3 Support
 Tivoli NetView for UNIX and NT

skantner@dsscorp.com@tkg.com on 04/02/2001 03:04:55 PM

Please respond to IBM NetView Discussion <nv-l@tkg.com>

Sent by:  owner-nv-l@tkg.com

To:   nv-l@tkg.com
Subject:  [NV-L] Ruleset Performance Question

I am faced with monitoring router and node outages and issuing email/paging
alerts for multiple groups of routers and nodes.    Different actions must
be taken depending on which group the routers/nodes belong to as they
belong to different customers that we monitor from a central Netview.   I
am not having difficulty with coding the rulesets (classic pass-on-match
and reset-on-match scenarios) to handle this, but I am in a quandary as how
to best do the implementation from a performance and ruleset maintenance
perspective.    I have read James' 1998 doc on ruleset performance, but I
am still left wondering about a few things.

My goals are:

1. Minimum number of rulesets in order to minimize maintenance when adding
new customers.
2. Efficient ruleset design so that I avoid bringing nvcorrd to its knees.


1. Is it better to have a few large rulesets that do multiple smartset
queries to determine a node's collection membership, or many small rulesets
with a single smartset query per ruleset (essentially a 'ruleset per
2. Could a larger ruleset set that does multiple smartset queries use
common pass-on-match/reset-on-match logic, or is this a bad idea?  To wit:

                                                      ----> Query Smartset1
Event                Trap               /
Stream  ------> Settings1       ------> Query SmartSet 2
--------------Input1------>   Pass
                \                                  \
/                                        on
                  \                                  -------> Query
Smartset 3----/        /--Input2------>  Match
                   \                                 ----> Query Smartset1
-----\         /
                     ->  Trap               /
\     /
                          Settings2       ------> Query SmartSet 2 ------>/
                                                     -------> Query
Smartset 3----/

3. Is there any advantage/disadvantage to using the ROUTERDOWN_EV trap over
IBM_NVNDWN_EV when looking for router downs?

Thanks and Regards,


Scott P. Kantner
Lead Systems Engineer
Distributed Systems Services

NV-L List information and Archives: http://www.tkg.com/nv-l

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web