How about just putting those bundles in your sandbox? I would be interested to have something to measure the performance of EventAdmin. It does not necessarily need to be a Pax Exam compatible test.
Greetings, Marcel On Apr 4, 2012, at 19:50 PM, Carsten Ziegeler wrote: > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
