Out of curiosity, did anybody ever write a "test" that we can run to benchmark the performance of EventAdmin. I don't mean an ad-hoc test but something we can put in the Felix repository (in a sandbox).
Greetings, Marcel On Apr 4, 2012, at 19:30 PM, Carsten Ziegeler wrote: > Hi Joel, > > yes, we noticed some performance problems as well - apart from the problem > you mentioned in our case it was a very high load on the service registry > (which in addition could also cause deadlocks in the framework). > So I reimplemented the whole thing (FELIX-3321). You can find the code now > in the latest trunk, so you could just build the version from trunk and see > how it performs. It basically changes the way how event handlers are > fetched from the registry and how the event topic is compared - filters are > now only used if really required, the main checks are done by simple string > comparisons. > > For our really simple performance test case with more than 1 million > events, it took more than 30 seconds with the old implementation, the new > one processes the same amount in less than a second. > > Not sure about your problem if events getting eaten up. With the new impl > it should be much easier to track this down (if it still happens) > > Regards > Carsten > > 2012/4/4 Joel Schuster <[email protected]> > >> Carsten et al.,**** >> >> ** ** >> >> I've been running some profiling against some test components using >> EventAdmin. I'm seeing some really degenerate behavior that's causing some >> real slowdowns for message delivery coming from a few places.**** >> >> ** ** >> >> Environment: running 400+ messages per second and with 15+ topics with >> various levels of hierarchy.**** >> >> ** ** >> >> Because of the general ‘brute force’ means by which >> org.apache.felix.framework.capabilityset.CapabilitySet.convertArrayToList >> works, and how the multiple layers of >> org.apache.felix.framework.capabilityset.CapabilitySet.match work when >> topics have multiple layers of hierarchy with the names I can double the >> throughput of EventAdmin by simply changing my topic names to one layer of >> hierarchy. Of course I lose the advantages of the fiters, but if I can >> double the throughput then it seems worth it.**** >> >> ** ** >> >> Even then it’s still taking more than half a millisecond (optimally, >> sometimes many tens of milliseconds) for any particular message to make its >> way through the EventAdmin system, being pushed and handled. That seems >> like a long time. Part of the overhead comes from the >> org.apache.felix.framework.ServiceRegistry.getService and ungetService >> calls that happen for every single message push.**** >> >> ** ** >> >> It seems to me that some sort of caching of previous search results in >> each of these domains would be well worth the effort.**** >> >> ** ** >> >> Carsten, I noticed that you had commented about an improved EventAdmin in >> the sandbox. Can you please point that out to me, I’d like to try it out.* >> *** >> >> ** ** >> >> Also, I’ve notice that the EventAdmin is not delivering all the events >> that are pushed to a topic. Small percentages (1 / 1000) are simply being >> eaten up somewhere… I can’t seem to track down any reason or log for why >> the events simply disappeared.**** >> >> ** ** >> >> ** ** >> >> Thanks all for consideration.**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> **** >> >> ** ** >> >> - Joel**** >> >> ** ** >> >> ** ** >> >>> -----Original Message----- >> >>> From: Carsten Ziegeler [mailto:[email protected]] >> >>> Sent: Tuesday, January 24, 2012 2:55 AM >> >>> To: [email protected] >> >>> Subject: Re: EventAdmin Asynchronous/Parallel EventHandler >> >>> >> >>> Hi, >> >>> >> >>> we haven't implemented this feature yet but will do once the final >> >>> spec is publically available. >> >>> >> >>> I've written a new implementation of the event admin which is in the >> >>> felix sandbox atm, this one is significanlty faster than the old >> >>> implementation from trunk. >> >>> >> >>> Regards >> >>> Carsten >> >>> >> >>> 2012/1/18 DBinSD <[email protected]>: >> >>>> >> >>>> Thanks Holger, this is exactly the info I was looking for. It sounds >> like >> >>>> the Async Unordered Events might get me the performance I was looking >> >>> for >> >>>> (though the implications of 'unordered' events might be a problem in >> some >> >>>> applications). I will keep an eye out for an implementation of this >> >>>> feature. >> >>>> >> >>>> Thanks again >> >>>> Chris >> >>>> >> >>>> >> >>>> >> >>>> Holger Hoffstätte-4 wrote: >> >>>>> >> >>>>> On 18.01.2012 03:35, DBinSD wrote: >> >>>>>> Does the felix implementation of the EventAdmin service support the >> >>>>>> delivery >> >>>>>> of events, asynchronously and in parallel to multiple listeners at >> once? >> >>>>>> It >> >>>>> >> >>>>> This was addressed as part of RFC 157 ("Updates to EventAdmin") >> >>> sometime >> >>>>> in 2010 and accepted, though I don't remember offhand what the >> >>>>> implementation status was/is. IIRC it was part of 4.3. >> >>>>> >> >>>>> The solution added a set of constants that express basic delivery >> >>>>> behaviour/expectations. Not really enforceable end-to-end QoS >> >>> constraints >> >>>>> (which are impossible in Java anyway) but better than nothing. >> >>>>> >> >>>>> --snip-- >> >>>>> >> >>>>> 5.2 Asynchronous Unordered Events >> >>>>> >> >>>>> The following constants are added to EventConstants. This allows an >> >>> Event >> >>>>> Handler to indicate that it is willing to relax the event ordering >> >>>>> requirements so that Event Admin can optimize delivery. >> >>>>> >> >>>>> String EVENT_DELIVERY = "event.delivery" >> >>>>> Service Registration property specifying the delivery qualities >> requested >> >>>>> by an Event Handler service. >> >>>>> >> >>>>> Event handlers MAY be registered with this property. Each value of >> this >> >>>>> property is a string specifying a delivery quality for the Event >> handler. >> >>>>> >> >>>>> The value of this property must be of type String, String[], or >> >>>>> Collection<String>. >> >>>>> >> >>>>> Since: >> >>>>> 1.3 >> >>>>> See Also: >> >>>>> DELIVERY_ASYNC_ORDERED >> >>>>> DELIVERY_ASYNC_UNORDERED >> >>>>> >> >>>>> String DELIVERY_ASYNC_ORDERED = "async.ordered" >> >>>>> Event Handler delivery quality value specifying the Event Handler >> requires >> >>>>> asynchronously delivered events be delivered in order. Ordered >> delivery >> >>> is >> >>>>> the default for asynchronously delivered events. >> >>>>> >> >>>>> This delivery quality value is mutually exclusive with >> >>>>> DELIVERY_ASYNC_UNORDERED. However, if both this value and >> >>>>> DELIVERY_ASYNC_UNORDERED are specifed for an event handler, this >> >>> value >> >>>>> takes precedence. >> >>>>> >> >>>>> Since: >> >>>>> 1.3 >> >>>>> See Also: >> >>>>> EVENT_DELIVERY >> >>>>> >> >>>>> String DELIVERY_ASYNC_UNORDERED = "async.unordered" >> >>>>> Event Handler delivery quality value specifying the Event Handler does >> >>> not >> >>>>> require asynchronously delivered events be delivered in order. This >> may >> >>>>> allow an Event Admin implementation to optimize asynchronous event >> >>>>> delivery by relaxing ordering requirements. >> >>>>> >> >>>>> This delivery quality value is mutually exclusive with >> >>>>> DELIVERY_ASYNC_ORDERED. However, if both this value and >> >>>>> DELIVERY_ASYNC_ORDERED are specifed for an event handler, >> >>>>> DELIVERY_ASYNC_ORDERED takes precedence. >> >>>>> >> >>>>> Since: >> >>>>> 1.3 >> >>>>> >> >>>>> See Also: >> >>>>> EVENT_DELIVERY >> >>>>> >> >>>>> --snip-- >> >>>>> >> >>>>> Also see >> >>>>> http://stackoverflow.com/questions/7018762/when-to-use-osgi- >> >>> eventadmin-and-when-not >> >>>>> for BJ's official answer. >> >>>>> >> >>>>> hope this helps >> >>>>> Holger >> >>>>> >> >>>>> --------------------------------------------------------------------- >> >>>>> To unsubscribe, e-mail: [email protected] >> >>>>> For additional commands, e-mail: [email protected] >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> -- >> >>>> View this message in context: http://old.nabble.com/EventAdmin- >> >>> Asynchronous-Parallel-EventHandler-tp33158446p33162303.html >> >>>> Sent from the Apache Felix - Users mailing list archive at Nabble.com. >> >>>> >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: [email protected] >> >>>> For additional commands, e-mail: [email protected] >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Carsten Ziegeler >> >>> [email protected] >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: [email protected] >> >>> For additional commands, e-mail: [email protected] >> > > > > -- > Carsten Ziegeler > [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
