[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=15605790#comment-15605790 ] Alexander Klimetschek edited comment on SLING-5277 at 10/25/16 4:39 PM: AFAICS, SLING-6165 just moves this to a different place, but has the same problem that the admin/service 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. Note that this issue is not about admin vs. service user but about performance of creating this extra session, which adds cost to every single sling request, even if not used at all. was (Author: alexander.klimetschek): 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] [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=15603702#comment-15603702 ] Alexander Klimetschek edited comment on SLING-5277 at 10/25/16 12:53 AM: - Attached new patch [^SLING-5277-new.patch] which solves the above discussed issue. The patch is against revision 1730513 though, right after the org.apache.sling.servlets.resolver 2.4.2 release, as afterwards a lot of sling changes happened that requires many bundles to update (which I couldn't easily do in my environment). I haven't got good test numbers yet (only tested this issue together with other changes), but independent tests would be great! /cc [~joerghoh] was (Author: alexander.klimetschek): Attached new patch [^SLING-5277-new.patch] which solves the above discussed issue. I haven't got good test numbers yet (only tested this issue together with other changes), but independent tests would be great! /cc [~joerghoh] > 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] [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=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)
[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=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)
