Conference azur::mcc

    1) I don't think that would work... I think if you ask for an entity
       by name, it has to exist in the domain that the notify request is
       entered against.  (I could be wrong)
    
    2) This will be quite memory intensive.  540 notify requests will be
       a lot more resource intensive than 1.  The notification propagation
       will work properly however. 
    
    3) Sorry, I don't have any suggestions.

    Greetings,
    What exactly is being expanded during notification?  
    
    	(Example:  Entity = node4 mynode circuit * adjacent node *
    		   Event List = adjacency up, adjacency down  )
    
    Heavy CPU usage and heavy buffered I/O occurs during notification
    creation and enabling; therefore, lots of access to namespace (in this
    case, remote DNS).
    
    Any suggestions on speeding up?
    
    -Dan

    Hi Dan, Pete
    
    Thanks for joining in on the discussion.
    
    In .0, What I need expanding in the notify request is collector *, in
    the domain hierarchy.  Nothing else.  Except I guess the fact that the
    hierarchy is walked means that all domains need to be identified before
    they can be walked.  Therefore Dan, your question...
    
        What exactly is being expanded during notification?
    
    is very valid.  Is it: "domain xxx... member *" and then look for
    everything that is actually of class domain - or is it possible to
    expand just the domain entities?  (And collectors because that is what I
    am trying to notify against?)  Perhaps one of the developers would like
    to comment here as to how they do this?
    
    re: .1, Pete, although my initial guess would have been in line with
    yours, I find in practice that if you notify against a top level domain
    and reference an entity further down, notification DOES ACCEPT IT!  So my
    suggestion would probably work.  But does it buy me anything?  Don't
    know!
    
    Finally, I don't think the question of 1 notify with 1800 objects being
    monitored vs 600 notifies each with 3 objects has not really been
    addressed.  Could one of the developers indicate whether there is a
    major difference in this regarding resources/startup speed or not?
    
    Thanks guys,
    
    chris
    

>        What exactly is being expanded during notification?
    
>    is very valid.  Is it: "domain xxx... member *" and then look for
>    everything that is actually of class domain - or is it possible to
>    expand just the domain entities?  (And collectors because that is what I
    
    It depends at what level you're asking the question.  Between the
    notification FM and the domain FM, there is a way to ask for only
    members of a given class, and I believe that is what is being done
    here.  But the domain FM may well have to look through all members of a
    particular domain before being able to discern what class each member
    is.  I can't remember if the domain FM stashes its stuff in DNS or a
    MIR file.
    
    Also, the notification FM has to traverse the domain hierarchy anyway,
    so even if you ask for just collector * it's going to have to do domain
    * as well (to see the hierarchy).
    
>    Finally, I don't think the question of 1 notify with 1800 objects being
>    monitored vs 600 notifies each with 3 objects has not really been
>    addressed.  Could one of the developers indicate whether there is a
>    major difference in this regarding resources/startup speed or not?
    
    Sorry I didn't put any official sounding stamp on my reply.  :^)  I was
    part of the notification development team.  
    
    resources:
    
    It is MUCH MORE EXPENSIVE in terms of memory to have 600 notify
    requests created.  If it boils down to looking at the same 1800 objects
    either way, there are certain sets of data that will be the same size
    in both scenarios.  But the overhead of each notify request, plus the
    overhead of the threads (and on unix, there is a thread in both the
    IMPM process and in the Notification FM process) makes the 600 notify
    requests much more of a pig.
    
    startup:
    
    I would make an educated guess and say that 600 notify requests, even
    though they are all looking at much smaller chunks of the domain
    hiearchy, would cause your machine to thrash so badly that a single
    notify request which looks at the entire hierarchy would perform better.
    
    Hope this helps.

    If you have the opportunity, try implementing the 600 small notify requests
    vs the 1 big notify request, and measure the results.  (Give yourself a
    break and put the notify requests in a file.)
    
    Theory is theory, but the reality may be different (i.e. I could be
    wrong... it's happened before).

    Thanks again Pete for your explanations.
    
    I do understand that sometimes it is best to go try it - and prepare to
    be suprised - so over the next few weeks I'll try to see the customer
    and do a few experiments.  It probably won't be until early mid august
    now.  This whole startup business is complicated by the fact that we
    are trying the new 1.3 dns 'low confidence' feature and experimenting
    with the size of the dns cache so there are many variables!  I'm trying
    to gather as much info up front so we can do some sensible tests.  My
    questions around size of dns cache were placed in note 901 of the dns
    notesfile if you want to read that as well.
    
    regards, chris