You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Alexander Klimetschek (JIRA)" <ji...@apache.org> on 2016/01/04 22:25:39 UTC

[jira] [Comment Edited] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit

    [ 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:24 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 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.

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)