[
https://issues.apache.org/jira/browse/SLING-11654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688371#comment-17688371
]
Joerg Hoh commented on SLING-11654:
-----------------------------------
Documentation:
* the Logger {{org.apache.sling.jcr.resource.AccessLogger.statistics}} on TRACE
will display statjstjcs when a ResourceResolver is closed. The overhead of this
operation is low, and it could also be turned on on a test environment.
* the logger {{org.apache.sling.jcr.resource.AccessLogger.operation}} on TRACE
logs a stacktrace for every of these situations (including the name of the
resource). This creates a massive overhead (both in terms of additional latency
and log volume), so it is advised to enable this just for a short moment
(seconds!) or for a single request.
** a JcrNodeResource was instantiated
** a JcrValueMap is created from a resource
> 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)
