[jira] [Closed] (SLING-11654) Create repository access metrics

["Joerg Hoh (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-11654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joerg Hoh closed SLING-11654.
-----------------------------

> Create repository access metrics
> --------------------------------
>
>                 Key: SLING-11654
>                 URL: https://issues.apache.org/jira/browse/SLING-11654
>             Project: Sling
>          Issue Type: Improvement
>          Components: JCR
>    Affects Versions: JCR Resource 3.2.2
>            Reporter: Joerg Hoh
>            Assignee: Joerg Hoh
>            Priority: Major
>             Fix For: JCR Resource 3.2.4
>
>          Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> In recent rounds of performance analysis and improvement in AEM I found that large improvements in rendering time can be achieved the easiest by removing access to the Sling/Oak repository. 
> Prominent ways for repository access are these
>  * ResourecResolver.getResource(path)
>  * Resource.getValueMap()
>  * (and others)
> This is mostly interesting in the context of JCR/Oak, as there the amount of code to run behind these calls is much higher than in the case of SyntheticResources or Servlets, where I never saw performance problems.
> My goal:
>  * Look at a single request and see in what situations it does a repository access. Having a suitable amount of the stack helps to map it back to a specific point in the rendering process. And from there it can be assessed if any improvements are possible.
>  * Unlike a profiler which calculates wall-time (CPU time spent in processing) I am interested in the pure number of invocations of the above operations. This allows to perform the analysis on a developer machine by performing single requests.
>  * In that situation the performance overhead is a no problem. It's just that if this feature is not used there should not be a negative impact.
> Non-Goal:
> * If an application does not use Sling, but rather direct JCR these cannot be measured; but that need to be addressed on an Oak level.
> I am not aware of any tooling in Sling which allows us to get that information; while I could probably get the raw numbers from Oak, I cannot get any context from there.
> I thought about the use of profiler, but these often sample the stacks at a defined frequency (often in the range of miliseconds), which makes them miss repository access, as these normally are done in a sub-milisecond range in case of a TarMK repository. Also I already know what takes long (the repository access itself), so the wall-time information does not help much.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)