[
https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081834#comment-15081834
]
Alexander Klimetschek edited comment on SLING-5277 at 1/4/16 9:25 PM:
----------------------------------------------------------------------
Good catch. It doesn't need to be created in the DESTROY event.
For why it didn't affect my performance tests: Since the destroy event happens
at the end of the request, it doesn't affect the latency of request handling
from the client pov. I was focusing on the jcr & sling authentication overhead.
It should still affect overall throughput, though.
And probably the core problem was that concurrent resource resolver creation
had a synchronization bottleneck that was fixed recently by SLING-4937 – see my
comment there – which made any additional resource resolvers created per
request a lot more costly. Still, this should be fixed here and a whole new
resource resolver not unnecessarily created, since the sling servlet resolver
doesn't have control over how costly creation of a resource resolver is
(affected by custom resource providers, other sling issues like SLING-4937,
jackrabbit issues...).
was (Author: alexander.klimetschek):
Good catch. It doesn't need to be created in the DESTROY event.
For why it didn't affect my performance tests: Since the destroy event happens
at the end of the request, it doesn't affect the latency of request handling
from the client pov. I was focusing on the jcr & sling authentication overhead.
It should still affect overall throughput, though.
And probably the core problem was that concurrent resource resolver creation
had a synchronization bottleneck that was fixed recently by SLING-4937 – see my
comment there – which made any additional resource resolvers created per
request a lot more costly. Still, this should be fixed here and not
unnecessarily created, since the sling servlet resolver doesn't have control
over how costly creation of a resource resolver is (affected by custom resource
providers, other sling issues like SLING-4937, jackrabbit issues...).
> Performance: per thread script resolver (admin session) is always created
> even if cache is hit
> ----------------------------------------------------------------------------------------------
>
> Key: SLING-5277
> URL: https://issues.apache.org/jira/browse/SLING-5277
> Project: Sling
> Issue Type: Bug
> Components: Servlets
> Reporter: Alexander Klimetschek
> Attachments: SLING-5277.patch
>
>
> Since SLING-3441, for every request, a new admin / privileged session is
> [created in the
> SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532].
> It is created before the script/servlet cache is checked, so in most cases
> when the cache is hit it is never used, but the cost of creating an extra
> session (which can vary, especially with concurrent traffic) is incurred.
> The per thread script resolver can be created lazily instead of directly in
> the event to avoid this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
