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

[Dan Kegel]

Duncan Grisby wrote:
> 
> On Thursday 21 February, Dan Kegel wrote:
> 
> > The benchmark measures how long it takes to do a parallel echo
> > (i.e.
> >   for all servers do
> >      invoke_deferred echo request
> >   for all servers do
> >      collect results )
> > as a function of the number of echo servers running on the
> > computer (both the client and all servers are running locally).
> 
> Perhaps I'm being dim, but I don't see how this benchmark measures
> anything to do with footprint at all. You are measuring how well
> send_deferred() works.

I'm doing both.  The send_deferred() part should be easy compared to
the other part of the benchmark, which is forking N copies of the
echo server.   And there's some evidence for that: the benchmark does
fine, with response time increasing slowly with N, until the system
almost runs out of memory.  At which point response time shoots
above 100ms rather quickly.

> In omniORB, send_deferred() doesn't scale very well at all, since it
> creates a new thread for each deferred request. Almost all the latency
> you are seeing will be in thread switching. Improving deferred sends
> might be a nice thing to do in a future omniORB version, but there has
> never been any demand for it.

Given my 'it measures when you run out of memory' observation above,
do you feel a little better about the benchmark, at least on limited-memory
systems?
 
> Your pipe based server also has the huge advantage that the pipes are
> already opened before you do the "calls". omniORB opens a connection
> to the server on the first invocation. If you do a call to each server
> before the calls that you time, you'll find it goes quite a lot
> faster, since the TCP connections will already be open.

That's a good point.  I should do a version that includes the time
to open a tcp socket in the measurement, that would be much more fair.
 
> Anyway, all of this performance stuff is interesting, but it has
> absolutely nothing to do with memory footprint.

Still think so?  I wish it were true, but corba programs do use
a lot of memory, and simply forking 28 of them does seem to exhaust
all available memory on my 64 MB embedded system.  I'd be overjoyed
to hear that I was building omniorb or the app wrong, and that the
overhead was actually a lot lower...

- Dan