felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Paulin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4638) Event Admin - Less locking on event handler timing
Date Fri, 19 Sep 2014 13:12:33 GMT

    [ https://issues.apache.org/jira/browse/FELIX-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140446#comment-14140446

Bob Paulin commented on FELIX-4638:

Carsten, thank you for the review.  I was thinking that if there are multiple handlers listening
to an event even if they ignored blacklisting there might be a performance gain by executing
them in different threads.  I did not however do any testing around this theory :).  I expect
that there may be some threshold where it's worth it to send the handlers into the thread
pool.  This threshold would likely vary by the number of handlers and the duration of the
handlers.  While calculating the number of handlers is straightforward, calculating duration
is tricky so it might be worth looking into adding a flag to the handlers indicating it should
be run in the pool.  This might provide some additional flexibility to your idea of executing
the blacklisted or non-blacklisted with separate approaches.  I'll see if I can setup some
tests and get some data.  Either way I think it makes sense to add back in the code to run
the handlers that ignore blacklisting in the same thread. 

> Event Admin - Less locking on event handler timing
> --------------------------------------------------
>                 Key: FELIX-4638
>                 URL: https://issues.apache.org/jira/browse/FELIX-4638
>             Project: Felix
>          Issue Type: Improvement
>          Components: Event Admin
>            Reporter: Bob Paulin
>            Assignee: Carsten Ziegeler
>            Priority: Minor
>             Fix For: eventadmin-1.4.4
>         Attachments: FELIX-4638.patch, FELIX-4638b.patch
> The locking that is done for the blacklist timing seems to degrade performance significantly
Felix is under stress with multiple firing handler callbacks for each event.  I'd like to
discuss an alternative approach with less locking that still  guarantees proper event ordering
per the OSGi spec.  Basically instead of using the CyclicBarriers (Rendezvous) on a per handler
basis we could use a count down latch to only await after all handlers are complete.  Then
instead of using a stopwatch based timer the JMX Current Thread Cpu Time which counts CPU
time for the application code and any IO performed on it's behalf filtering out time context
switching between threads to provide proper blacklisting.  
> Here are my test results.
> Baseline(Event Admin 1.4.2):
> 15 Threads
> 100000 Async Events per Thread
> 7 Active Handlers per Event
> For a total of 10500000 Handler Events Executed in 40000 - 45000ms
> With the same parameters above but a CountDownLatch I see the execution time drop to
around 25000ms.   The improvement is noticeable because the stress test includes 7 active
handlers per event.  The improvement is less noticeable with applications that only register
one or 2 handlers for an active event such as in the PerformanceTestIT.  Thoughts on changing
how this locking occurs?  Concerns with using the JMX timings?

This message was sent by Atlassian JIRA

View raw message