felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: EventAdmin Performance
Date Wed, 04 Apr 2012 17:44:44 GMT
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 <joel.schuster@gmx.com>
> 
>> 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:cziegeler@apache.org]
>> 
>>> Sent: Tuesday, January 24, 2012 2:55 AM
>> 
>>> To: users@felix.apache.org
>> 
>>> 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 <cdiebner@gmail.com>:
>> 
>>>> 
>> 
>>>> 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: users-unsubscribe@felix.apache.org
>> 
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>> 
>>>>> 
>> 
>>>>> 
>> 
>>>>> 
>> 
>>>> 
>> 
>>>> --
>> 
>>>> 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: users-unsubscribe@felix.apache.org
>> 
>>>> For additional commands, e-mail: users-help@felix.apache.org
>> 
>>>> 
>> 
>>> 
>> 
>>> 
>> 
>>> 
>> 
>>> --
>> 
>>> Carsten Ziegeler
>> 
>>> cziegeler@apache.org
>> 
>>> 
>> 
>>> ---------------------------------------------------------------------
>> 
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> 
>>> For additional commands, e-mail: users-help@felix.apache.org
>> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> cziegeler@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message