[Scalability] Re: Performance

[Sai-Lai Lo]

>>>>> Mundlapati, Jawahar writes:

> Since I found from Web that OmniORB2 has good performance numbers, I
> started evaluating OmniORB2. My testing enviroment is 100,000+
> distributed objects/1000 bytes size with 10,000 interactive clients and
> 1 million transactions per day. 

> Once these objects are created method invocation is very fast.  But
> unfortunately OmniORB2 took 16+ hours to create 100,000 objects, which
> is undesirable for performance critical applications.  Can you suggest
> me any alternate approaches ?

I CC this reply to omniorb-list because this may be of interest to other
members. 

It seems to me the reason it took 16+ hours to create 100,000 objects is
because your machine is paging heavily during this time. Given that you
said the objects are 1000 bytes each, your process's VM size would be at least
100M. Do you do your test on a machine with that much memory? Anyway, I
modified the example program eg2_impl to create 100000 objects. It took 67
seconds to create them all on a Sun Ultra 1. This average out to 670 usec
per object.

Lets look at the performance parameters:

1. 1 million transactions per day
     This works out to a 24hour average of 11.57 per sec. In other words,
     your server has an average of 86.4 msec to process each call. Now
     given that omniORB's overhead is only 0.67 msec on an Ultra over
     ethernet, it uses less that 1% of the allocated processing time.
     Obviously this is just a rough calculation but it seems to me at this
     transaction rate, omniORB is hardly a limiting factor.

2. 10,000 interactive clients
     For each process, there is a limit on the number of TCP/IP connections
     that it can accept. On Solaris, the usual limit is around 1000. On NT
     workstation, the document says it is 256 though I have not verified
     this and do not know whether this limit can be adjusted. 

     The number of clients that can concurrently invoke on the server is
     obviously limited by this per process limit. So I would say omniORB
     should be capable of supporting 10,000 interactive clients on Solaris
     *if less than 10%* of the clients invoke on the server at the same time.
     I should say that this is possible only if the ORB is capable of
     closing idle connections and reconnect automatically when it needs
     to. The omniORB_2.2.0 release cannot do this but the coming release
     can.

3. 100,000+ distributed objects/1000 bytes

     As long as your machine has enough resources to load all the objects
     in memory this is not a limiting factory. If this is not the case and
     if only a small percentage of the objects are active at any time, it
     would be sensible to load the objects on-demand. Loading object on
     demand is not supported by omniORB_2.2.0 or the coming
     release. However, this is one feature that is high on our to-do
     list. I'm going to work on this once I get the coming release out of
     the door. 


Further scaling
---------------

What about 10x the performance parameters? To support that sort of scale I
think one should be looking at load balancing among a group of workhorse
machines and a few front ends to act as the first point of contacts. To
build this architecture, the GIOP LOCATION_FORWARD feature comes in handy
because the client can transparently redirect the requests from a server
that only acts as the medium to the server that serves the real objects.
omniORB has full support for location forwarding. To keep this message
short, I won't go into other issues in this 2-tier approach. May be some
other time...


Personally, I think omniORB is quite capable of scaling to support very
large distributed object systems. We don't have all the bits in place yet
but we are getting closer everyday.

Regards,

Sai-Lai Lo

-- 
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