[omniORB] Performance comparison of OmniEvents and OmniNotifiy

[Alex Tingle]

Hi Chris,

On 1 Mar 2005, at 16:44, Christopher Petrilli wrote:
> Well, the background is this, and perhaps it will help understand my
> approach.  I was originally using Elvin (http://www.mantara.com/),
> which has an amazingly simple binding to most languages, and is a
> breeze to use.  However, I was using CORBA for all the other services.
>  My goal was to unify on one "architecture" and use CORBA Events or
> Notification framework.  I'm wondering if, however, that's too much
> complexity?

Surely you can't get much simpler than the OMG Event Service? If 
anything it's a bit too simple for the real world.

>> I've done some limited comparison testing between the two. As I 
>> recall,
>> the latency is about the same for isolated individual events. As the
>> volume of events increases, omniEvents starts to pull ahead, but
>> omniNotify's performance is still good.
>
> In this case, I would need some of the capabilities of omniNotify, as
> I'd like to be able to choose which events I see, and perhaps only if
> they meet certain requirements.  THis is something that can be done
> easily in the constraint language in Elvin.

As I mentioned to Fred Prin earlier, omniEvents can filter by CORBA 
type. If you need a constraint language, then you have to use something 
else. Surely though, running a complicated set of constraints against 
each message is going to kill performance in a high volume environment?

>> I think this is to be expected - omniEvents is optimised for high
>> volumes. It starts to batch-up events as the volume increases.
>
> Does it do any form of batching on the edges of the service? In other
> words, does it push/pull 1 event at  a time from the supplier and
> consumers, or does it actually move batches?  The spec seems to imply
> it must be a one at a time method.

The 'batching' to which I refer is entirely within the event channel. 
The specification forces delivery to be one-at-a-time at the edge. 
However I'm free to use any optimisation I like between federated event 
channels. As I said, I plan to use multicast.

Of course you could implement batching even at the edges, but then you 
wouldn't be using the OMG Event Service - you'd be using a proprietary 
interface. I don't think that's necessary - just have omniEvents 
running on each client machine. All the network traffic can then be 
optimised, but the interface you see is still standards compliant. The 
one-at-a-time delivery then always happens over the local loopback (or 
even through a pipe - on Unix).

I prefer this solution to a batching interface, because it keeps the 
complexity in the middleware, where it belongs. The client code remains 
as simple as possible.

> I would love to hear your take on omniEvents v. Elvin?

I'll read up on it.

-Alex Tingle

-- 
:: alex tingle
:: http://www.firetree.net/consulting/
:: alex.tingle AT firetree.net  +44-7901-552763