[omniORB] Measuring omniorb's footprint. New footprint benchmark.

[Duncan Grisby]

On Monday 25 February, Dan Kegel wrote:

> >  Synchronous calls, Unix                      364
> 
> Wow, sychronous calls faster than parallel calls?  Something's out
> of whack.

Not really. Thread switching is very expensive. That's why we try
really hard to avoid any switching along the call chain, and why
omniORB goes fast compared to other designs in the common case of
synchronous calls.

The result is highly artificial since the client and servers are all
on the same machine, meaning "network" latency is tiny. With even a
little bit of network latency, I suspect the thread switching overhead
would be worth it, compared to the extra time taken to do synchronous
calls.

One other thing that speeds up the synchronous calls is that I did the
test using the static invocation interface, so it doesn't have the
overhead of DII. A fairer test would have used DII for the synchronous
version, but I wanted to get a feel for how fast it could possibly be.

It is possible to perform CORBA deferred synchronous calls in a way
that doesn't involve using threads at all. I suspect that that is what
TAO is doing to get such good performance. It's something that could
be done in omniORB, but it's not a trivial change (converting to use
thread pooling was trivial). The big advantage of the current design
is that it is very easy to understand, compared to the state machine
that would be needed for doing it without threads.

>    Is there a way to prefill the thread pool so no
> thread creation occurs during the measurement period?

No, but as long as the number of servers at the end of the test is
greater than the thread pool size (default 100), there will be no
thread creation going on in the last tests.

> (BTW, I hate deadlock etc. so much that in my programs, I never create
> a thread after program startup, and never have threads interact
> except via queues if I can help it.  I shuddered with horror when
> I heard omniorb3 created threads willy-nilly.  To each his own, I guess.)

Avoiding deadlock is indeed tricky. I don't see how it makes any
difference when you create your threads, though. Would you care to
explain why creating threads after startup makes deadlock more likely?


> > The normal way to avoid potential problems is to create a simple
> > single-threaded forking proxy. 
> 
> Look closely at footprint1.cc :-) 

Oh yes. I believed what the pseudocode says, rather than looking at
the implementation.


> I'd been holding off on trying omniORB4.  Is it ready for general use, then?
> I should be able to give it a shot sometime this week.

It's ready for general use. There are a few obscure things to finish
off before the first beta release, but it's almost there. There are
certainly external users already using it in real applications.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --