Preventing slow realm response times during periods of inactivity

Follow
    Applies to:
  • Legacy SecureAuth IdP
Deployment model:
  • On Premises
  • SecureAuth IdP Version Affected: All

    Description:

    Occasionally, realm authentication may take more than 20 seconds and ultimately time out.

     

    Cause:

    This could be the worker process being terminated during periods of inactivity.  By default IIS will shut down worker processes after 20 minutes of inactivity.  In realms which are infrequently used this can lead to a delayed response when requests arrive while the new worker process is spawned and loads up.

     

    Resolution:

    There are two changes you can make in order to help alleviate the problem. These can be used individually or in conjunction:

    In IIS Manager, go to Application Pools, click on the application pool responsible for the realm, usually called ".NET v4.5", then click "Advanced Settings..." in the right hand pane and scroll down to the "Process Model" section. 



    Here you can:

    1. Increase "Idle time-out(minutes)" to allow a longer time period before the worker process is stopped.

    And/or

    2. Change the "Idle time-out Action" to Suspend so instead of killing the process it is suspended to disk and resumes a lot faster than a normal startup.  More info here:
    https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-85/idle-worker-process-page-out-in-iis85

    The above will help prevent slow response times when the realms are up and running but you may also be interested in this KB article which explains how to preload and start the worker processes when IIS first starts up or restarts:
    https://support.secureauth.com/hc/en-us/articles/360019885251-Pre-Load-IdP-Realms-to-address-IIS-Warm-Up-Slow-Start-latencies

     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    1 out of 1 found this helpful

    Comments

    2 comments

    Please sign in to leave a comment.