[omniNotify] omniNotify Performance Tuning Question / subscri ption bug

Fri Aug 8 11:47:37 BST 2003

Robert,

> Once a proxy is marked as a problem (exception occurred when
> using to its connected client) the proxy no longer holds onto
> events queued for the client, but the proxy itself is not
> destroyed right away.  To do a final cleanup of such 'dead'
> proxies and their related admins and filters, you need to
> use 'cleanup both' on the server using the do_command API.

Is it safe to call server->do_command( "cleanup both" ) at regular
intervals? For example our Notification Service application wraps the
omniNotify library and makes use of the AttNotification interface to
retrieve the server and the initial eventChannelFactory. From there it
doesn't make use of the interactive interface or anything other than
standard CosNotify interfaces. Is it ok to call "cleanup both" at regular,
configurable, intervals throughout the lifetime of the application? This
will not effect filters/admins/proxies that are in a normal state?

Thanks again
Cameron

-----Original Message-----
From: omninotify-list-bounces at omniorb-support.com
[mailto:omninotify-list-bounces at omniorb-support.com] On Behalf Of
Cameron Rochester
Sent: Thursday, August 07, 2003 2:13 AM
To: 'Robert E. Gruber'; omninotify-list at omniorb-support.com
Subject: RE: [omniNotify] omniNotify Performance Tuning Question

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