[omniORB] Performance comparison of OmniEvents and OmniNotifiy

[Christopher Petrilli]

On Tue, 1 Mar 2005 17:21:41 +0000, Alex Tingle
<alex.tingle at bronermetals.com> wrote:
> 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.

Well, in this case, I was reffering to the API interface, which is so
simple on Elvin that it's almost laughable to call it an API.  This is
how you would connect and subscribe to something matching the
constraint language in Python:

connection = elvin.connect("elvin://random.foo.org")
sub = connection.subscribe("require(event_id)")
sub.add_listener(insert_event)
sub.register()
connection.run()

insert_event is a method I've written to actually do the work of
dealing with an incoming event.

Now, I am working on a layer over the Event Service that shows a
similarly simple API.  95% of the code in CORBA is templated
requirements to bootstrap the system.

> > 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've run Elvin with 2,500 events per second without using more the 10%
CPU on an iMac G5.  It's pretty impressive, actually.  I haven't had a
chance to push omniEvents anywhere near that yet, as I've only
recently started looking at moving to a pure CORBA environment.  While
I generally argue against early optimization, I do have to worry about
performance in this scenerio.

Individual sources can generate hudreds of events in a second, and the
overall system may have to deal with 5-10 thousand events per second. 
That necessitates dealing with things a bit differently.

> >> 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.

I understand.  I'm looking at it because I need to use the pull model,
which unfortunately sets up a polling situation, and given the event
load, I can imagine polling 500x a second to get events could be a
killer, even with appropriate back-off algorithms.  Hense, I had
designed it to grab events in batches of  up to 100, and work from
there.

> 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).

This is something I hadn't thought of, honestly.  So in that case, I
would need to build conduits between the various systems, yes?  Is
there some way to do that programatically, rather than through command
line utilities?

> 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.

Always a good goal, and one I appreciate.  Dealing with things 1 at a
time is ideal, but I'm not sure if my event load really allows for it.
 The overhead cost can become enormous.

> > I would love to hear your take on omniEvents v. Elvin?
> 
> I'll read up on it.

Thank you ever so much for your help!  In many ways, I'm dealing with
similar scale issues to what is addressed in the telecom space with
call detail records, etc.  Unfortunately, many obvious solutions that
seem to work at lower load levels collapse completely, and I'm forced
to punish them unbeleivably in test rigs to see what can be done to
fix the loading issues.

Chris
-- 
| Christopher Petrilli
| petrilli at gmail.com