[omniORB] omniEvents 2.6.0 (All new stable release)

[Alex Tingle]

Janet,

Janet Tvedt <tvedt at noao.edu> wrote:
> Has anyone done any performance testing with this new version?

I've done some performance testing on my PC (Athlon 2600+, Debian Linux,
2.4 kernel). Server & client on the same machine to factor out network
latency.

>From memory:

For single events, the performance is similar to omniNotify. Latency is
typically 600-900us for a small event (payload one 'long'). omniEvents
scales better than omniNotify though: Latency increases more slowly as
the number of events per second rises.

I've tested an older version of the code with realistic message sizes,
and several suppliers/consumers, and it coped well with >600 events/sec.


I think you'd have to start using non-standard UDP transports to further
improve the latency. The most important factor governing message
throughput is message size.

There is a tool (events) that comes with omniEvents that allows you to
record event streams and play them back later. This allows you to tune
performance with a single known test dataset. If you decide to try this
tuning approach, I'd appeciate a copy of your capture files, and any
comments you have.

regards,

-Alex

--

> --
> Janet Tvedt
> National Solar Observatory
> 
> On Fri, 2004-10-08 at 08:56, Alex Tingle wrote:
> > website: http://omnievents.sf.net/
> > 
> > I am proud to announce omniEvents 2.6.0, the culmination of nearly a
> > year's development and testing.
> > 
> > omniEvents 2.6.0 is an almost entirely new implementation of the OMG
> > 
> > Event Service Specification v1.1 for omniORB. It builds upon the
> > foundation of omniEvents v2.4.
> > 
> > This new version contains a number of significant enhancements:
> > 
> >  o Each Proxy type is individually designed for optimal performance,
> >    and minimal use of system resources.
> > 
> >  o Implements a sub-set of the Fault-Tolerant CORBA specification.
> >    Servers may be configured to operate in pairs - if one fails then
> >    clients automatically switch over to the alternate.
> > 
> >  o Event channels can be federated, which allows multiple servers to
> >    share the load of delivering events to many clients across a wide
> >    area network.
> > 
> >  o Event channels can be configured to only pass on events of a
> >    particular CORBA type. Combined with channel federation, this
> >    allows Consumers to choose which type of events to receive.
> > 
> >  o The server runs as a daemon on Unix or a service on Windows. A
> >    SysV style init file can be automatically installed on Unix, to
> >    get you up and running with minimum fuss.
> > 
> >  o omniEvents is now much better documented. There are detailed
> >    installation instructions, full code documentation and even a
> >    tutorial on writing an Event Service client.
> > 
> >  o Implements OMG Event Service Specification v1.1 - with the
> >  correct
> >    disconnection semantics. This makes it much easier to write
> >    clients that can disconnect cleanly.
> > 
> > Full documentation is here:
> >  http://omnievents.sf.net/doc/index.html
> > 
> > WARNING: This release is NOT backwards compatible. If you are
> > upgrading from 2.4.1 or earlier, then remove your current
> > installation before installing the new version.
> > 
> > -Alex Tingle
> 

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