Bob Paulin created FELIX-4638:
---------------------------------
Summary: 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
Priority: Minor
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
(v6.3.4#6332)
