Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-12028

Policy endpoint can take a long time to respond to first ever authorization request

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 14.0.0, 14.5.0
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Rank:
      1|hzuoon:

      Description

      Bug description

      The first ever request to OpenAM's authorise endpoint takes significantly longer than following calls to the same endpoint. This is particularly noticeable when a large amount of policies have been configured. I believe this is because on the first ever call, the endpoint constructs an in memory tree of all the policies. 

      This came to light during performance testing the agents with 100,000 policies. We were finding that the agent's 4 second timeout was being hit on the first call. Obviously 100,000 is far more policies than are currently used in reality, but may become the norm when features such as UMA get taken up by customers.

      It could also be argued that it's only on the first ever call to the instance so it's not something we are going to see very often in production, however with auto-deployable clusters creating new OpenAMs on the fly, this is an issue that could be seen fairly regularly in a production environment. 

      How to reproduce the issue

      1) Deploy OpenAM and create a large amount of policies. 

      2) Restart OpenAM

      3) Get a user session and perform a policy evaluation (either via an agent, or by calling the /openam/json/policies?_action=evaluate endpoint directly)

      Expected behaviouR

      A response time in a similar range to following calls to the same endpoint

      Current behaviour

      A longer response time than following calls to the same endpoint.

       

       

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            rich.riley Rich Riley [X] (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: