[omniNotify] omniNotify Performance Tuning Question

[Robert E. Gruber]

omniNotify is supposed to scale with clients much better than Cameron describes.

The poor scaling he reports may be due to a bug that was recently fixed (a lock was held
across push calls where it should not be).  

Perhaps Cameron would you be willing to get the latest omniORB and omniNotify from
sourceforge and try benchmarking again?   

For those interesting in getting stuff from sourceforge, I will send another email
describing how to do this.

A new omniORB 4 release will happen soon, and this will be followed by the long-awaited
(!) omniNotify 2.0 official release (which depends on the upcoming omniORB 4, at least for
the Windows port).  

Next email: getting sources.

-- Bob

-----Original Message-----
From: omninotify-list-bounces at omniorb-support.com
[mailto:omninotify-list-bounces at omniorb-support.com] On Behalf Of Cameron Rochester
Sent: Tuesday, August 05, 2003 8:27 PM
To: omninotify-list at omniorb-support.com
Subject: RE: [omniNotify] omniNotify Performance Tuning Question

Patrick,

How many consumers are connected to the notification service? What is the
complexity of the filters that you have in place?

I have found with testing that performance drops off considerably as
consumers increase (it is much worse than a linear degradation). However,
evaluating more complex filters and having less consumers is actually a lot
faster. Our system used to have multiple connections to the notification
service from the same client. I changed the approach and reduced the number
of connections while increasing the filter complexity and found performance
to be much better while reducing load on the service.

Having said that, I never saw the kind of lag that you are experiencing.
Running the service on a (relatively) slow dual processor solaris box (2 x
400MHz, 512Mb RAM) and sending/receiving events from a seperate windows
client (P4 2.4G, 512Mb RAM) the notification service would still manage
approx 10 events/sec with 1700 unique subscribers. The faster approach was
to create a filter with a constraint expression seq with 1700 individual
constraints (but only one connection) and then perform simple filtering on
the client side to ensure the correct subscriber receives the correct event.
With this approach the notification service sustains ~500 events/sec with
1700 subscribed types. With 1-2 subscribed types it would manage upwards of
600 events/sec.

So, the service should be able to handle significantly more than 15-20
events minute, but we probably need a bit more information regarding the way
in which you are consuming events.

Cheers
Cameron Rochester

-----Original Message-----
From: Patrick Vaughan [mailto:plvaugh at sandia.gov]
Sent: Wednesday, August 06, 2003 6:55 AM
To: omninotify-list at omniorb-support.com
Cc: omniorb-list at omniorb-support.com
Subject: [omniNotify] omniNotify Performance Tuning Question


Greetings,

I've been running an application which uses omniORB/omniORBpy with 
omniNotify.  Everything works, but the performance in respect to event 
passing seems quite slow.  The load on the system is about 15-20 events 
per minute.  I'm seeing delays of around a full minute from the time an 
event is sent to the time the event arrives.  I've run the application 
on both a Mac OS X 10.2.6 system and a Red Hat Linux 7.3.2 system.  The 
delay is about the same regardless of the system I run the application 
on.

Any suggestions on how to decrease the delay in event delivery would be 
appreciated.

Thanks.



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

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