Joerg Hoh created SLING-11654:
---------------------------------

             Summary: 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


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.

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)

Reply via email to