[jira] [Commented] (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=15605790#comment-15605790 ] Alexander Klimetschek commented on SLING-5277: -- AFAICS, SLING-6165 just moves this to a different place, but has the same problem that the admin resolver is created for each request (upon SlingRequestEvent.EventType.EVENT_INIT it does rrf.getServiceResourceResolver(null) in ScriptingResourceResolverFactoryImpl), even if it is never accessed, because nothing asks for resolving a resource type etc. > 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-new.patch, 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)
[jira] [Commented] (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=15605714#comment-15605714 ] Radu Cotescu commented on SLING-5277: - I guess so. But we also haven't reached consensus in SLING-6165. > 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-new.patch, 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)
[jira] [Commented] (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=15604544#comment-15604544 ] Carsten Ziegeler commented on SLING-5277: - Isn't this superceeded by SLING-6165? /cc [~radu.cotescu] > 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-new.patch, 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)
[jira] [Commented] (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=15574823#comment-15574823 ] Jörg Hoh commented on SLING-5277: - Is there any progress on this? > 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)
[jira] [Commented] (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=15081843#comment-15081843
]
Alexander Klimetschek commented on SLING-5277:
--
To fix the DESTROY handling, we can just call
{{this.perThreadScriptResolver.remove()}} without the {{get()}} beforehand and
the not null check.
However, how do we close the per script resource resolver then, in case it was
created? {{ThreadLocal.remove()}} doesn't return the removed object. It seems
we have to do the {{ThreadLocal.get() & initialValue()}} logic ourselves
(again), inside {{getScriptResourceResolver}} using {{ThreadLocal.set()}}, so
that {{ThreadLocal.get()}} will return null if no resolver was set for the
current thread.
> 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)
[jira] [Commented] (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=15081834#comment-15081834 ] Alexander Klimetschek commented on SLING-5277: -- 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)
[jira] [Commented] (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=15074862#comment-15074862 ] Carsten Ziegeler commented on SLING-5277: - I think there is something wrong with your patch and your performance tests: In your version, when the DESTROY event is received in the onEvent() method, this.perThreadScriptResolver.get() is called which creates the resource resolver (initial value) just to be closed again. Therefore I fail to see how this can be more performant as the resource resolver is created anyway on each request - nothing is saved. In addition, changing the creation from the INIT event to an initial value is also a change in behaviour as with the initial value the resource resolver is always cloned on the first get. While with the previous it is only created if an event occurs. I'm not sure about this impact though. > 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)
[jira] [Commented] (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=15006105#comment-15006105 ] Alexander Klimetschek commented on SLING-5277: -- The patch does exactly that. In my performance tests it made a noticeable difference, since the session creation cost essentially outweighed the cache benefit. > 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)
[jira] [Commented] (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=15006088#comment-15006088 ] Carsten Ziegeler commented on SLING-5277: - We can create it lazily but it needs to be created even if the resolution is coming from the cache as the script implementation might use the script resolver > 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)
