[omniORB] performance limits of omniNames (COMM_FAILURE)

[Duncan Grisby]

On Wednesday 7 November, =?UTF-8?Q?Jarom=C3=ADr_Tal=C3=AD=C5=99?= wrote:

>   we are using omniORB as a communication platform in just created
> domain registry system for .cz TLD (about 350000 domains, released as
> open source on http://fred.nic.cz). Both python and c++ parts are really
> good. Many thanks to authors!
>   
>   But recently we had noticed on our production server (omniorb-4.0.6),
> that in high load, omniNames started refuse to answer 'resolve' command
> throwing CORBA/COMM_FAILURE. I managed to simulate this situation (hope
> it's the same situation) with omniorb-4.1.0 by this simple script:

There are two scalability issues here. One is omniORB scalability. Its
default policies are to use one thread per connection, and to keep idle
connections open for quite a while. That means it can hit the OS's limit
on open file descriptors or on running threads quite quickly. To help
with that, you can set omniORB to thread pool mode (with quite a large
pool size), and set the inConScanPeriod lower so idle connections are
closed much more quickly. You can also make sure the process has as high
a limit of file descriptors as the OS will allow.

The other issue is scalability of omniNames itself. It's a really simple
thing that isn't intended to scale much. In particular, if you store a
lot of names in a flat structure, it's dreadful because it uses a linear
scan through linked lists of names when looking things up. If you need
to store lots of name bindings, you should come up with some kind of
hierarchy to avoid too much linear behaviour.

What are you using omniNames for?  It might well be better for you to
use something else to store object references.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --