How To: Reduce Slow or Timed-Out Realm Responses Caused by IIS Worker Process Recycling

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected: Earlier than 26.2

     

    Overview

    An Internet Information Services (IIS) Application Pool stops its worker process after a period of inactivity, and does not start a new one until the next request arrives. This causes realm access to be slow, or to time out entirely, whenever a request is the first one after that worker process has stopped — whether the worker stopped because the realm sat idle, or because the Application Pool itself just restarted or recycled. This article explains two ways to reduce or eliminate that delay:

    • Use Method 1 to reduce how often the worker process is stopped for inactivity in the first place.
    • Use Method 2 to have IIS start the worker process immediately whenever it restarts, instead of waiting for the first request.

    These can be used individually or together.

    In this article

     

    Method 1: Reduce Worker Process Shutdown for Inactivity

    By default, IIS stops an Application Pool’s worker process after 20 minutes of inactivity. In realms that are used infrequently, this leads to a delayed response the next time a request arrives, while a new worker process starts and loads.

    1. Open IIS Manager and go to Application Pools.
    2. Click the Application Pool responsible for the realm — usually .NET v4.5 — then click Advanced Settings in the right-hand pane and scroll down to the Process Model section, as shown below.

    Advanced Settings dialog showing the Process Model section, with Idle Time-out (minutes) and Idle Time-out Action highlighted.

    From here, either or both of the following will help:

    • Increase Idle Time-out (minutes) to allow a longer period of inactivity before the worker process is stopped.
    • Change Idle Time-out Action to Suspend, so the worker process is suspended to disk instead of terminated — resuming from suspension is significantly faster than a full startup. See Microsoft’s Idle Worker Process Page-Out in IIS 8.5 for details on this setting.



     

    Method 2: Preload the Worker Process After IIS Restarts

    Method 1 reduces stops caused by inactivity, but does not help with the delay that follows an IIS restart or an Application Pool recycle — the first request after either of those still waits for the worker process to start from scratch. This method has IIS start and preload the worker process immediately when it restarts, so it is already warmed up by the time a real request arrives.

    There are known incompatibilities between Application Initialization and Application Request Routing (ARR). It is not recommended to use Application Initialization on machines with ARR installed.

    Install the Application Initialization module:

    1. Open Server Manager, click the Manage menu, then click Add Roles and Features.
    2. Step through the wizard (installation type, destination server) until you reach Server Roles.
    3. Expand Web Server (IIS)Web ServerApplication Development, select Application Initialization, as shown below, then finish the wizard.

    Add Roles and Features wizard with the Application Initialization feature selected under Web Server > Application Development.

    Configure IIS to keep Application Pools running and preload realms on start:

    1. In IIS Manager, click the server name under Start Page, then open Configuration Editor and set the section dropdown to system.webServer/applicationInitialization.
    2. Set doAppInitAfterRestart to True, as shown below, then click Apply.

    Configuration Editor showing the doAppInitAfterRestart setting under system.webServer/applicationInitialization set to True.

    1. Click Application Pools. For each Application Pool that has realms you want this feature enabled for — typically .NET v4.5 — right-click it and select Advanced Settings.
    2. Set Start Mode to AlwaysRunning, as shown below.

    Advanced Settings dialog for an Application Pool with Start Mode set to AlwaysRunning.

    Since the Application Pool is now always running, Idle Time-out no longer applies to it — there is no need to also configure Method 1 for the same Application Pool.

    1. Under Sites, right-click each realm (for example, SecureAuth1) that you want preloaded and select Manage ApplicationAdvanced Settings.
    2. Set Preload Enabled to True, as shown below.

    Advanced Settings dialog for a realm site with Preload Enabled set to True.

    1. For Windows Server 2016, you also need to tell IIS which pages to use to warm up each realm. In the Admin Console, open the System Info tab for the realm and click Decrypt.
    2. Back up D:\SecureAuth\SecureAuth<realm>\web.config, then edit it.
    3. In the <system.webServer> section, add the following. If the realm does not use a Web Service data store, omit the last two initializationPage lines:
    <applicationInitialization doAppInitAfterRestart="true">
      <add initializationPage="/secureauth.aspx" />
      <add initializationPage="/webservice/membershipws.svc" />
      <add initializationPage="/webservice/profilews.svc" />
    </applicationInitialization>
    1. Repeat steps 5–9 for every realm you want preloaded.
    2. Run iisreset.

    Special Considerations:

    Even with preloading configured, an IIS restart or Application Pool recycle still needs some lead time to load every preloaded page — this can take up to a couple of minutes depending on how many realms are being preloaded, and in rare cases has been seen to take hours. During this time, access will still seem slow, so it is worth scheduling Application Pool recycles for outside normal usage hours, and splitting realms across more Application Pools if the number of realms being preloaded is large.




    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.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.