[omniNotify] omniNotify Performance Tuning Question

Thu Aug 7 15:12:46 BST 2003

Robert,

I grabbed the latest omniNotify snapshot (and the latest omniORB snapshot)
and checked the update.log, it contained the following entry:

"Changed things so event lock is not held across push 
(required different approach for omniORB3 vs. omniORB4).
Also remove all events from outgoing queue of a proxy
that gets _pxstatus set to RDI_Exception."

I assume this is the fix you have mentioned? After a few hours of building I
was ready to go again.

One other thing - does omniNotify clean up invalid
suppliers/consumers/filters if a client application crashes?

On to the testing....

environment:
- Solaris 2.8 (Sunfire V480 - 2 x 1.1G with 4,096MB RAM. GCC 3.2.1) running
omniNotify
- Win2k (P4 2.4G with 512MB RAM. VS 6.0) running test client

I performed the test again and found performance to be a little better. For
the implementation of the client please refer to the "omniNotify
subscription bug" email I also sent today, I use the same application for
gathering performance data.

Performance for unique subscriptions had improved but still exhibited very
poor perfomance with > 32 unique subscribers. Performance for unique
subscriptions was generally double the last build with > 16 unique
subscribers. Shared subscriptions again show what approaches a flat
performance rate.

For a graph of this data please see http://ii.net/~rochest/graph.gif. The
graph shows performance with up to 1024 subscribed types. Our system can
easily require in excess of 1000 subscribed event types.

Regards
Cameron Rochester

-----Original Message-----
From: Robert E. Gruber [mailto:gruber at research.att.com]
Sent: Wednesday, August 06, 2003 11:34 PM
To: 'Cameron Rochester'; omninotify-list at omniorb-support.com
Cc: Robert E. Gruber
Subject: RE: [omniNotify] omniNotify Performance Tuning Question

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: graph.gif
Type: image/gif
Size: 17672 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omninotify-list/attachments/20030807/d342d135/graph-0002.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graph.gif
Type: image/gif
Size: 17672 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omninotify-list/attachments/20030807/d342d135/graph-0003.gif