Re: [nv-l] Ruleset efficiency using Trap Settings versus Event Attributes
Well, there are no benchmarks for nvcorrd
that are that fine. But I would be surprised if you saw an appreciable
difference between (1) and (3).
NetView uses method (4) because our
specific trap ids are almost unique (how many others use a eight-digit
number like 58916864?) but if they did, we'd have to expand that
to include the enterprise id as well. In that case, we'd probably
be using method (2) or else putting a single Trap Settings node ahead of
the multiple Event Attributes. That would be marginally less-efficient
code wise but it would make the ruleset easier to read, both in the editor
and in the rs file.
Bottom line, I think that using (2)
is probably as efficient code-wise as anything else might be
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
|"Van Order, Drew \(US
- Hermitage\)" <dvanorder AT deloitte DOT com>
Sent by: owner-nv-l AT lists.us.ibm DOT com
09/09/2004 11:23 AM
|<nv-l AT lists.us.ibm DOT com>
|[nv-l] Ruleset efficiency
using Trap Settings versus Event Attributes|
We are testing Compaq traps and there are a considerable number of them
under Compaq's Enterprise ID. Suppose you have 200 traps under one
enterprise ID, but only 15 that need forwarding to TEC. Is it more
1. Use a Trap Settings node set at the enterprise ID
2. Use a Trap Settings node with only the 15 traps highlighted under the
3. Use an Event Attributes node set for equal to enterprise ID
4. Use an Event Attributes node for each specific trap (like TEC_ITS)
I think we have a lot of inefficiency in our NV ruleset and like TEC, a
tight ruleset means best event processing.
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law.
If you are not the intended recipient, you should delete this message.
Any disclosure, copying, or distribution of this message, or the
taking of any action based on it, is strictly prohibited.