What’s the overhead of getting a resource resolver instance?

[prestonModOp]

I inherited code for an application that uses resourceResolver instances quite liberally. Notably this code has a custom tag library for generating anchor tags. When called it takes the link and checks to see if it’s a page in the AEM using a resourceResolver. In the case of the navigation or footer it does this hundreds of times in total, per server hit.

We’re struggling with performance issues and I set JProfiler against the application and that’s the only thing that jumps out. Moderately high average CPU time making the getResourceResolver call. 

So I’m wondering what the overall overhead of this method is in case what’s happening is slowdown caused by so many calls to this method. 

[shaileshb584084]

Ideally it does not creates the spike as described.

Are you closing all the resource resolver once the job is finished or not?

Ideally there should be a service which utilizes the resource resolver in a method and close it once the work is finished.

Please explain in detail if you have some different use case and how are you using the resource resolver instance.

Thanks

[prestonModOp]

That's what we're doing. We're opening them for a specific bit of work and then closing them when done.

[prestonModOp]

That's what we're doing. We're opening them for a specific bit of work and then closing them when done. The use case here is that we have this tag library that interrogates links and determines if they're a web page in the system. If they are it formats them a specific way. What this means, though, is that when you build the header in the site you effectively call this method hundreds of times. That's why I was wondering about the overhead of opening all of these ResourceResolver objects over and over.

[prestonModOp]

Sorry for the duplicate.

[Kiran_Vedantam]

Whenever we use ResourceResolver, it’s a 100% chance that you will open a JCR session. Hence, we should call “close()” on every resolver once the job is done.

API calls which open a JCR resource:
SlingRepository.loginAdminstrative() , DEPRECATED!
SlingRepository.loginService()

API calls, which create a Sling ResourceResolver:
ResourceResolverFactory.getAdministrativeResourceResolver(), DEPRECATED!
ResourceResolverFactory.getResourceResolver()
ResourceResolverFactory.getServiceResourceResolver()

Also, when we have already opened a ResourceResolver, adapting it to a Session.class will just expose the internally used JCR session; it will not create a new Session for it. Therefore we do not need to close the session.

Thanks,

Kiran Vedantam.

[prestonModOp]

We're closing them. And we're using the getResourceResolver() method to retrieve them.

[Shubham_borole]

Not sure if the desired use of the resourceresolver can be reduced, based on the required resource/property. You can use service resolvers and instantiate the resolver using try-with-resources (https://docs.oracle.com/javase/8/docs/technotes/guides/language/try-with-resources.html) With this, as long as the try bolck is done the resource resolver and associate sessions will close.

Some links here - https://github.com/Adobe-Consulting-Services/acs-aem-samples/blob/master/core/src/main/java/com/adob...

https://www.tothenew.com/blog/access-content-repository-via-getserviceresourceresolver-in-aem6sling7...

Hope this helps

[prestonModOp]

We're closing resources correctly. What jumped out at me when I looked at our codebase in JProfiler was how long it took to even open a resourceResolver, regardless of the fact that we're closing it correctly. And we open hundreds of them per request. That's why I was curious about the overhead of even opening one.

[Shubham_borole]

Got you. Could there be a possibility of using user's request resolver if/where applicable? We don't have to close those. Getting curious too since using service resolvers at many places is common for me too

[shelly-goel · Accepted solution]

@prestonModOp  In the use case like this where you need to check each url and rewrite it, using sling rewriter pipeline would be better. Sling has the possibility to rewrite the output/generated markup of a page via a pipelining feature and it is activated in AEM by default (used for the AEM-builtin link checker and link rewriting features). You would have to create a new transformer-type and add it to the rewrite configuration.

Code Examples: https://helpx.adobe.com/experience-manager/using/aem63_link_rewriter.html#AddJavafilestotheMavenproj...

https://www.flexibledesigns.rs/creating-a-link-rewriter/

[arunpatidar]

Hi,

We are also using link scanning to identify internal links with specific format using subservice session via sling output rewrite pipeline. we did not see any performance issues, even though we have a header and footer with internal links.

I would suggest using sling rewriter pipeline which allows you to restrict link scanning based on path, link extension, attribute, tags etc. This will help to improve performance. 

[Jörg_Hoh]

Opening a ResourceResolver is normally opening a JCR session. Which comes with some overhead.

Some time back I profiled a publish instance in load tests and found that eliminating a single filter, which opened and closed a JCR session (and doing some work in between) increased the number of requests my publish was able to handle by ~ 5%.

So if you do that lots of times during the rendering of a page, it will negatively impact the performance of the page rendering.

Jörg