[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