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
cc:
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.
Questions:
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
customer')?
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
--------------------------------------
Scott P. Kantner
Lead Systems Engineer
Distributed Systems Services
www.dsscorp.com
610.927.2025
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|