[ 
https://issues.apache.org/jira/browse/SLING-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946927#comment-14946927
 ] 

Robert Munteanu edited comment on SLING-4999 at 10/7/15 2:22 PM:
-----------------------------------------------------------------

I've attached  patch which removes all synchronisation and instead stores data 
in an immutable object help by an atomic reference.

There should be no locking anymore, at the expense of (slightly) more 
computation done per request.

Due to the small response time I was unable to get meaningful performance 
results with my test run.

[~cziegeler], thoughts? Also [~joelrich] might be interested, he's doing lots 
of performance work recently

_Edit_: typo


was (Author: rombert):
I've attached  patch which removes all synchronisation and instead stores data 
in an immutable object help by an atomic reference.

There should be no locking anymore, at the expense of (slightly) more 
computation done per request.

Due to the small response time I was unable to get meaningful performance 
results with my test run.

[~cziegeler], thought? Also [~joelrich] might be interested, he's doing lots of 
performance work recently

> Check synchronization in RequestProcessorMBeanImpl
> --------------------------------------------------
>
>                 Key: SLING-4999
>                 URL: https://issues.apache.org/jira/browse/SLING-4999
>             Project: Sling
>          Issue Type: Improvement
>          Components: Engine
>    Affects Versions: Engine 2.4.2
>            Reporter: Carsten Ziegeler
>             Fix For: Engine 2.4.4
>
>         Attachments: 
> 0001-SLING-4999-Check-synchronization-in-RequestProcessor.patch
>
>
> Each and every request goes through RequestProcessorMBeanImpl#addRequestData 
> which is a synchronized block. I think this is a rather heavy bottleneck for 
> request processing.
> In addition, some of the methods which do additional calculation are sync'ed 
> (like getStandardDeviationDurationMsec) but others are not (like 
> getStandardDeviationPeakRecursionDepth). This seems a little bit arbitrary to 
> me



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to