[omniORB] Bad performance with oneway invocation

[Duncan Grisby]

On Monday 14 July, Serguei Kolos wrote:

[...]
> 2. The asynchronous (oneway) round-trip time is from 3 to 10 times worse 
> with the omniORB.

Before I address the specific points, can I just ask what your
application is doing?  Does it reflect what this benchmark is doing?
The test you are performing has a client that sends empty oneway
invocations as quickly as it can, and a server that does no work in
the implementation of the oneway function. Does your application
really look like that?  Or even similar to it?

>     Let me explain: Using the default configuration I got ~60 us
> time per invocation with TAO and ~600 us per invocation for the
> omniORB.
>     I have found immediately that this huge time in omniORB produced
> by a large number of threads, which the server starts to process
> asynch requests coming over single connection.

omniORB's default behaviour is to assume, not unreasonably, that most
upcalls involve the application doing some work that takes some time,
and that clients do not try to do thousands of oneway requests at the
same time. Based on that, dispatching the oneways on separate threads
is a good idea. For your benchmark, setting
maxServerThreadPerConnection to 1 is the right thing to do.

>   I set then the
> maxServerThreadPerConnection to 1 and then get only one thread
> processing all the requests and obtained ~160 us time per invocation
> (which is already much better then before, but still much worse then
> with TAO).

I have checked in a couple of fixes to silly wasteful behaviour
(especially throwing lots of unnecessary exceptions) that should
improve the time a bit. I'd be interested to see your numbers now, but
I won't be surprised if TAO is still faster.

As you say in a later email...

[...]
>     But, unfortunately there is a serious performance
> drawback in one particular case - when a bunch of oneway
> messages is sent to the server over single connection. In this case
>  the server reads many of them with a single recv operation
> (which is very good!!!), but then it put each message into a separate
> buffer by copying it with the memcpy function (giopStream::inputMessage
> function in file giopStream.cc).
> This seriously downgrades the performance in such cases and
> noticeably (by a factor of 4) increases CPU consumption.
> Can this code be re-worked to eliminate memory copying?

It would be possible to avoid the copying, but to be honest I don't
think it's worth the effort. The large amount of copying only happens
in a very restricted set of circumstances, i.e. that a client is
sending requests so fast that TCP batches them into single packets,
_and_ that each request has very few arguments, so many requests fit
in a single ORB buffer. Furthermore, the overhead of copying is only
relevant to the overall invocation time if the operation
implementation does so little work that the time to do a memory
allocation and a memcpy is significant. Does your application _really_
look like this?

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --