Permission Check Servlet Performance Issue

[Kamal_Kishor]

We are using session based check to determine if a request should have access to a resource. This is causing massive performance hit on our instance when the load becomes slightly higher (it is relative as we have many sites hosted and have adequate infra for on-prem instance).

We are referring - https://experienceleague.adobe.com/en/docs/experience-manager-dispatcher/using/configuring/permissio...

Performance hit seems to be coming when requests are higher to check the permission and we are using session to check the permission - 

session.checkPermission(uri, Session.ACTION_READ);

Is there a better alternative to this approach without breaking it functionally?

thanks.

[Srinath_A]

• Background Job (Scheduler or Event-Driven):

  • Periodically or upon ACL/user changes, calculates which URIs each user (or group) can access.
  • Stores this permission map under "/conf/myapp/permissions/<userId>" as JCR nodes/properties.

• AuthChecker Servlet:

  • On HEAD requests (from Dispatcher), reads the user’s precomputed allowed URIs from JCR for the requested URI.
  • Approves access if allowed, denies otherwise.

• Fallback:

  • If no precomputed data exists, optionally fallback to live session.checkPermission to avoid lockout, and rebuild permissions as necessary.

[Kamal_Kishor]

@Srinath_A  - Thanks for your response.
We have pages which may have CUGs applied to them and we have multiple sites (100s at-least) and there could be different scenarios with CUGs applied to them.

I don't see the approach you have suggested to work very well for us. 

thanks.

[giuseppebaglio]

hi @Kamal_Kishor,

The dispatcher only calls your servlet for paths matching the auth_checker filter configuration, you could minimize unnecessary permission checks and restrict its usage to onlu htmls:

/auth_checker {
    /url "/bin/permissioncheck"
    /filter {
        /0000 { /glob "*" /type "deny" }
        # Only check items of interest
        /0001 { /glob "/content/mysite/secure/*.html" /type "allow" }
    }
}

I think this is the best solution since the servlet code is shrinked to very bare minimum of code leveraging already the fastest API possible.

Don't waste time rewriting the servlet, imho you should focus on reducing the number of permission checks via dispatcher filters and start Profiling analysis to find what the actual bottleneck could be.

[Kamal_Kishor]

@giuseppebaglio  - thanks for your response.

We are already filtering the requests to bare minimum.

We have use-cases where some set of pages would be requested about 10k times in span of few minutes. These are all legitimate requests and need permission check before being served from cache.

For that reason, we are hoping if there is a way to improve the permission check servlet.

thanks.

[arunpatidar]

Hi @Kamal_Kishor 

We have used ACS common's Permission Sensitive Cache Servlet, you can check their logic as well.

https://adobe-consulting-services.github.io/acs-aem-commons/features/utils-and-apis/permission-sensi... 

Code

https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/ad... 

[Kamal_Kishor]

@arunpatidar - Thanks Arun.
We have similar logic, additionally we are checking with session as well. This is referenced from adobe documentation - https://experienceleague.adobe.com/en/docs/experience-manager-dispatcher/using/configuring/permissio...

This statement takes bit of time under a valid heavy load (some campaigns)

session.checkPermission(uri, Session.ACTION_READ);

Wondering if anyone has been able to optimize for this or any other alternative which is session based.

If nothing works, we might get rid of this check, but currently we are unable to remove this and hoping to improve with session based check itself.

thanks.

[arunpatidar]

Hi @Kamal_Kishor 

For campaign the issue could not be due to PSC but the missing caching at dispatcher itself. Generally if url contains query string the dispatcher cache is skipped and PSC servlet never called instead GET request is reached at publisher.

If above assumption is correct then you need to think about removing champing param using rewrite rule, so that content serve from caching and reduce the overall load from publishers.