I've a performance test (and several others checking for deadlocks, event delivery etc). They all come as bundles which I deploy into a running instance and then check the results. I guess these could be converted to pax exam tests - but right now I don't have time to do that :(
Regards Carsten 2012/4/4 Marcel Offermans <[email protected]>: > 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] > -- Carsten Ziegeler [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
