Conference azur::mcc

4422.0. "DNS - Low confidence possible?" by BAHTAT::BOND () Thu Jan 21 1993 06:21

    British Telecom in the UK will be running DECmcc on a central system
    and 7 regional systems.  We are currently using DNS as the central MIR
    mastered on the central system and will one-day have replicas on each
    of the regional systems.  At present, the test regional system has a
    local MIR for the entities it is interested in; now 1000 but eventually
    2000.  In line with the other DNS notes in this conference, we find
    that DNS related performance is about 3 times slower than local MIR.
    
    Because our DECmcc registration data will be quite stable (once it has
    been fully loaded), we would like to use the DNS cache whenever
    possible to try to improve the performance, but from other notes in
    this conference, I understand that DECmcc uses medium or high
    confidence which bypasses the cache.  Is there anyway we can 'patch'
    DECmcc to try low confidence first?  Perhaps a future version of
    DECmcc could provide an environment variable eg MCC_DNS_CONF which
    could be set to LOW or MED or HIGH?
    
    At the moment, it takes the central system about 35 seconds to look
    into a domain with about 100 entities in it.  During this time, it is
    the two DNS processes that are hammering the CPU, not the domain FM. 
    (The regional system takes about 10 seconds to perform the same
    operation from local MIR.)  Once a domain has been opened, navigation
    within the hierachy is very good, even with multiple users, we are
    seeing just a few seconds for moving down and less for coming up.
    
    Enabling Notification at startup is rather worse!  Currently, the
    central system takes 8 to 9 minutes to enable notification for alarms
    and collector * in a 4 level dynamic domain hierarchy of about 90
    domains containing about 1000 entities.  When fully populated, this
    central system will have about 1200 domains containing 14,000 entities. 
    Extrapolating the above figures suggest that notification startup will
    take around 1.5 hours assuming the system isn't being asked to do
    anything else!  Now I know that 1.3 is aiming to improve this
    performance but I think in our case, we need to get performance
    improvements from all areas, like DNS as well as DECmcc itself.
    
    Of course, the above is not the full story because the central system
    is multi-user and there will be 10 different operators on x-terminals
    windowing into the system.  They will run under the same account so
    they will share management modules and so they *could* all read from
    the DNS cache if DECmcc used it.  Going a bit further, perhaps the
    domain and notification FMs should cache domain and entity information
    because that would greatly speed up the startup of subsequent users
    running under the same account.
    
    Thankyou for the performance improvements we have seen so far in
    DECmcc, but for our particular situation to be successful, I think we
    need a bit more from you!
    
    NB: Central System is 5000/240, 320MB memory, 3.2GB disk.  This might
    get the r4000 upgrade at some point and we eventually expect it to go
    to Alpha.  Regional Systems are 5000/240, 244MB memory, 3.2GB disk. 
    There are 20 5000/33 systems running DECmcc/UDM agent software
    monitoring terminal servers, bridges etc.  
    
    Chris Bond, Leeds, UK.

    Chris,
    this seems to be an excellent suggestion. While for most customers, the
    current code works best (albeit perhaps slower than desired, but it's
    designed to be accurate under changing network configurations), there
    are likely to be some (perhaps only a few) customers with quite stable
    networks who would be happy to accept the possibility that after a
    change, it might take a while for every MCC in the network to detect
    it.  However, the benefits are obvious - it should speed up many uses
    of MCC that involve the nameserver.
    
    One caveat - while we *think* it would perform better, it is probably
    worth trying it just to be sure!
    
    Finally, I would hope that rather than an environment variable, it
    would be implemented as a management parameter, managed via MCC - we
    have too many environment variables, and too few management parameters.
    
    Colin

                                                 
    RE: .0
    
    It was decided that the use of Low DECdns confidence level would be
    supported in DECmcc V1.3 SSB kit. 
    
    The confidence level can be settable (LOW/MED/HIGH) for initial "read" 
    operations only. (Some read operations may use High confidence when 
    expected information is not found using Low/Medium confidence)
    
    Setting the confidence level will be under optional logical/environmental 
    variable (MCC_DNS_CONF) control as you recommended. The default
    confidence level will be the same as in V1.2.
    
    William

    Colin, William, Thanks for the responses.  2 follow up questions to the
    developers if I may...
    
    1) DNS low confidence will be settable in 1.3 SSB; I know I'm pushing
    my luck here but is there anyway we could patch 1.2.3 so that it uses
    low confidence initially now?  I guess a failure at low confidence in a
    simple patched version would mean going straight to high confidence but
    I don't *think* that would matter in my situation as the central system
    is the master clearinghouse server anyway.
    
    2) Medium to Long term, are you looking to greatly improve the
    notification startup time and look-into domain time, perhaps by caching
    within the notification and domain FMs as I suggested in .0?  I do feel
    that the enormous startup time associated with large hierarchical
    domains is a real problem on customer sites, particularly after a major
    problem has occurred (eg powerfailure) and they have to wait longer for
    the management system to recover than the things it is managing!
    
    Thanks again,
    
    chris

    as to the notify questions, speeding up this whole subsystem has
    been a major goal of the 1.3 effort and a lot of progress has been
    made in speeding up the processing and support of the events subsystem.
    The acutal startup time of the request has been looked at but I
    do not believe it will meet with your goals as of yet.  Note though
    that notification FM has to go to DNS to find out the membership
    of each domain in the hierarchy, so the change to low confidence
    will have significant impact on this code path.