[omniORB] omniNames performance issues on Solaris 2.8.....

[steinhoffc@schneider.com]

     We are currently facing some serious performance issues accessing
omniNames.We have a process that reads the tree to retrieve object names
for processing, the reading of the tree seems to be very slow. Our initial
timing to read just over 10 came in around 60 seconds.

Current Environment
     Solaris 2.8
     omniOrb-4.0.0
     Solaris C++ Compiler 5.2

Application Code

   CosNaming::BindingIterator_var it;
   CosNaming::BindingList_var bl;
   const CORBA::ULong chunk = 100;
********************************************************
   theContext->list(chunk, bl.out(), it.out() );
***********************************************
   cDTCorba_guard1 it_guard(it);

   do {
      for( int i = 0; i < bl->length(); ++i )
      {
         CosNaming::Name found = toCosName(rwpath);
         found.length( found.length() + 1 );
         found[ found.length() - 1 ] = bl[i].binding_name[0];
         RWCString oneName( toString(found) );
         if( bl[i].binding_type == CosNaming::ncontext && contexts )
         {
            contexts->append( oneName );
         }
         if( bl[i].binding_type == CosNaming::nobject && objects )
         {
            objects->append( oneName );
         }
      }
      bl->length(0);
      if( ! CORBA::is_nil( it.in() ) )
***************************************************
         it->next_n( chunk, bl.out() );
*******************************************
   } while( bl->length() > 0 );


     We then started to look at our code and the omniNames installation.
Rational Quantify has shown that the block of code is completely dominated
by the list(), next_n() and destroy() methods to omniNames.It also
indicated that the iterator returned from the list() method was not nil,
but always returned an empty list from the next_n() call, and was then
destroyed.  This raised the question as to why a non-nil iterator was
returned in the first place.. This cause as to make the following code
change in the ./omniORB-4.0.0/src/appl/omniNames/NamingContext_i.cc.

   464    lock.readerOut();
   465
   466    // Possible performance patch ---------------------
   467    // Kendall Bailey 11/15/2002 ( Schneider National, Inc. )
   468    if( all->length() <= how_many )
   469    {
   470       // don't need an iterator.  All results can go back as a
   471       // result of this call
   472       bi = CosNaming::BindingIterator::_nil();
   473       bl = all;
   474       return;
   475    }
   476    // End patch --------------------------------------
   477
   478
   479    BindingIterator_i* bii = new BindingIterator_i(the_poa, all);

     After making this change we reran our test and thye time dropped from
60 seconds to 17 seconds. This seems to have made a very positive impact.

     We then looked at the ORB and saw that it was doing a lot of  LOCATE
requests  to the name service.  By going back to the
resolve_initial_references() call each time a lookup is going to happen, it
may be causing omniORB to 'forget' what it knows about the name service's
object reference.  So we  tried adding -ORBverifyObjectExistsAndType 0 to
your command line to avoid the LOCATE requests. This  took another 4
seconds off of the time.

     Right now we are down to 13 seconds, we beleive this should be much
faster. Any help in this situation would be greatly appreciated?

                                     Thanks

               Craig Steinhoff
               Schneider National Inc.