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

Dan Kegel dank@kegel.com
Mon, 25 Feb 2002 08:05:42 -0800


Duncan Grisby wrote:
> These tests are on a Dual Pentium II 450MHz machine, with 512MB RAM,
> running RedHat 7.1, Linux 2.4.12. It never gets close to running out
> of memory, so these tests are not affected by that.
> 
> [summary of dkcorbabench results with omniorb4:]
>  New thread per call, TCP:                    145
>  New thread per call, Unix:                   157
>  Thread pool, 100 threads, TCP                181
>  Thread pool, 100 threads, Unix               213
>  Thread pool, 5 threads, Unix                 230
>  Synchronous calls, Unix                      364

Wow, sychronous calls faster than parallel calls?  Something's out
of whack.  Is there a way to prefill the thread pool so no
thread creation occurs during the measurement period?
(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.)

I'll have to include a synchronous call measurement in the benchmark.
I had no idea doing parallel calls could be so suboptimal.
 
> I'll try everything on a laptop with 64MB RAM next, to see if I can
> manage to run out of memory.

Or boot with mem=8M, mem=9M, etc. to simulate a machine with only 8MB RAM.
I did, and Omniorb started working at 9MB, but Tao didn't work until 15 or 16MB.
(Results at http://www.kegel.com/dkcorbabench/#results)

> One thought about the memory use is that it's possible the fork() from
> the client is copying unnecessary stuff that isn't reclaimed during
> the exec(). Some platforms have difficulties forking from
> multi-threaded programs, or ones with lots of file descriptors open.
> It's not especially easy to test if this is happening.
> 
> The normal way to avoid potential problems is to create a simple
> single-threaded forking proxy. 

Look closely at footprint1.cc :-) 

> I'd be interested to see the results for your machines based on the
> current CVS version of omniORB 4 (or wait for tomorrow's FTP
> snapshot).

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.

Thanks for trying out the benchmark, I appreciate the data and hints.

- Dan