[omniORB] Performance comparison of OmniEvents and OmniNotifiy

Frederic Prin frederic.prin at silvaco.com
Tue Mar 1 11:04:51 GMT 2005


Hi,

I do use OmniNotify (2.0beta) since it comes up with omniORB-3.0.4 or
4.0.1.
The performance are good but, I don't know if I do not use it correctly
or it is something else but I found that OmniNotify suffers from huge
memory usage; inparticular when a lot of events are sent. The garbage
collector seems not to garbage anything (I debuged it, and saw that the
garbage thread works but the garbage methods do not delete anything).
So, when the notifd process (omniNotify daemon) is used for a long time,
it's memory size grow up to 1Go and its performance crash down...

I also did a purify but because of the garbage design, purify only
reports PLK "Potential memory Leak" (and not MLK).

I also tried all the tuning possible using the flag in the notifd.cfg
file.

(for info, I am currently using OmniORB-4.0.3/OmniNotify2.0beta. I did
not switch to OmniNotify2.1 since it seems that there was no change
regarding memory leaks. I am waiting for omniORB 4.1 to rebuild with
omniNotify2.1) 

So I am thinking to migrate from omniNotify to OmniEvents (that seems to
be more maintained.).
Alex, I am using StructuredEvents with filters and both push
cosummer/receiver, do you think it is easy to migrate to OmniEvents ?

Thanks

Fred


-----Original Message-----
From: omniorb-list-bounces at omniorb-support.com
[mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of Alex
Tingle
Sent: mardi 1 mars 2005 10:03
To: Christopher Petrilli
Cc: omniORB-list at omniorb-support.com
Subject: Re: [omniORB] Performance comparison of OmniEvents and
OmniNotifiy

Hi Chris,

On Mon, 28 Feb 2005 21:07:41 -0500
Christopher Petrilli <petrilli at gmail.com> wrote:

> I've been looking at the two options for distributing a high volume of
> events in a system, and looking at both of these, and searching the
> web, I've seen people argue that both are faster than the other.  I
> realize OmniNotify has more capabilities (some of which would be nice
> to have), but performance is the #1 issue in this case.
> 
> The events would be CORBA structs with about 35 fields in them.

(I am the author of omniEvents 2.4+)

Use omniNotify if you need the notification service. Use omniEvents if
your needs are simpler, or if you need the high availability feature.

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.

I think this is to be expected - omniEvents is optimised for high
volumes. It starts to batch-up events as the volume increases.

Older versions of omniEvents (2.3 and earlier) definitely suffer from
terrible performance at high volumes. The newer versions are more or
less a complete rewrite.

I've been planning to add a multicast transport to omniEvents (for
federated event channels), that should dramatically increase
performance. Contact me if you want to know more... I can drone on and
on about this if you like. ;-)

regards,

-Alex

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

_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list




More information about the omniORB-list mailing list