[omniORB] Scalability and maxStrands

[Andrew L. Sandoval]

I've seen too many situations where for one reason or another a server needs to
handle many, many more concurrent connections.  My two cents worth is that you up
this a long way (like up to a couple hundred), and let the implementor worry about
how to compensate for the load.

This is part of why I asked the question on omniNames about having more than one
server registered.  A CORBA name server may not be the answer, but, for CORBA to
be practical for serious, heavly-hit distributed applications that require any
degree of failover, there needs to be some method of finding servers that returns
either a list of servers (bindings) offering an object, or, selects one of the
available servers randomly or by load.

The bank that I work for is pushing to move to CORBA (from DCE), but, as much as
DCE has flopped in many areas (like reliability and cost), CORBA is still
drastically lacking in security and load handling.  I for one have not been
following the OMG's latest moves, but, I hope these things are being considered,
and, can be quickly implemented.  If so, CORBA will find its way to the mainstream
in the banks, etc., much faster...

Anyway, sorry for the preaching.  If that concurrency number can be bumped much
higher or made easily configurable that would be great!

Thanks,
Andrew Sandoval
sandoval@perigee.net


Sai-Lai Lo wrote:

> rshoup@tumbleweed.com (Randy Shoup) writes:
>
> >   We have run into a scalability problem using omniORB2.5.0, and wanted
> > some input.  It seems that the maximum number of strands per rope is
> > hard-coded to 5 in tcpSocketMTfactory.cc(529).  This means that a single
> > client can only have 5 simultaneous connections to any particular
> > server.  I have several questions:
> >
> > 1. Is there any reason why this value is hard-coded to 5?
>
> No particular reason for the value 5 other than that one would be hitting
> the server really hard with more than 5 concurrent calls.
>
> > 2. Would there be any problem increasing this value?
>
> No problem other that you also have to be aware of the per process quota
> imposed by the OS. Just change the value passed to the ctor of
> tcpSocketOutgoingRope in
>
> file:      tcpSocketMTfactory.cc:
> function:  tcpSocketMToutgoingFactory::findOrCreateOutgoing().
>
> > 3. Are there any plans to make this more configurable -- e.g., through
> > an ORB command-line argument or compile-time parameter?
>
> Any hard-coded parameter is bad! I'll look into making this configurable.
> Could be a ORB command-line argument. But on the other hand, we don't want
> to clutter the ORB init function with zillions of options not particular
> related to each other.
>
> > In addition, comments in rope.h(759) imply that for maxStrands of n, the
> > (n+1)'th request will block until a strand is released.  When we exceed
> > the number of strands, instead of blocking, omniORB throws an
> > exception.  This occurs both on NT4 and Solaris2.6.
>
> This is a bug if it does so. I'll check. On the other hand, could it be
> that you are hitting a limit on the server side? The server process may
> have exceeded the maximum per process socket quota? Of course if your test
> was done only between one client and one server we could discount this
> possibility.
>
> >
> > 4. Any chance this is fixed?
>
> Of course.
>
> Sai-Lai
> --
> Dr. Sai-Lai Lo                          |       Research Scientist
>                                         |
> E-mail:         S.Lo@orl.co.uk          |       Olivetti & Oracle Research Lab
>                                         |       24a Trumpington Street
> Tel:            +44 223 343000          |       Cambridge CB2 1QA
> Fax:            +44 223 313542          |       ENGLAND