Warmup Function

Overview¶

Warmup is a function that runs the initialization processes required right after Pleasanter starts, in advance.

An application running on ASP.NET Core has not yet completed processes such as loading tenants and site settings, establishing database connections, and compiling the executing code right after it starts. Because these processes normally run only when the first request is received, only that first user experiences a delayed response. The warmup function runs these initialization processes together when the application starts, and eliminates the response delay of the first request.

The warmup of Pleasanter has the following two features.

1. Until the initialization is completed, normal requests are blocked, and a response indicating that warmup is in progress is returned to users. This prevents access in an incomplete state before the initialization is finished.
2. The warmup status can be checked from the endpoint (/healthz) of the "Health Check Function". By referring to this status, load balancers and container platforms can route traffic only to instances whose warmup has completed.

Prerequisites¶

1. If warmup fails or times out, Pleasanter waits for the time specified by the WarmupFailureShutdownDelaySeconds parameter of BackgroundService.json, and then shuts down. Restarting after the shutdown follows the behavior of the execution environment, such as IIS, service management, or the container platform. While waiting, normal requests continue to be blocked, and 503 Service Unavailable is returned.
2. If warmup fails, the exception that caused it is recorded in the system log. In a configuration where the execution environment restarts instances automatically, starting and failing may repeat unless the cause is resolved. Check the cause, such as a failure to connect to the database, and take action.
3. Each instance runs warmup independently. When you operate multiple instances in a cluster configuration, instances that are still initializing may remain in the cluster as a whole until warmup is completed on all instances.

Flow of Warmup¶

Warmup starts automatically in the background when Pleasanter starts. No user operation or setting is required.

Warmup goes through the following three states in order.

Normal States¶

Abnormal States¶

Three states are defined for abnormal conditions.

For these abnormal states, refer to Prerequisites 1. and 2. and "Warmup Behavior Settings" below.

Warmup Behavior Settings¶

You can set the warmup timeout and the wait time before Pleasanter shuts down on failure with the parameters of BackgroundService.json.

BackgroundService.json¶

{
        : omitted
    "WarmupTimeoutSeconds": 180,
    "WarmupFailureShutdownDelaySeconds": 60
}

For details of each parameter, refer to BackgroundService.json.

Behavior During Warmup¶

Until warmup is completed, Pleasanter does not accept normal requests and instead returns a response indicating that warmup is in progress. The response differs depending on the type of request.

Requests from IIS Application Initialization are identified by the value of the User-Agent header. Initialization requests sent from IIS with the "IIS" settings described later are processed through this path.

However, requests to the following paths are processed without being blocked even during warmup.

1. The endpoint of the health check function (/healthz)
2. Static resources (/css, /js, /lib)
3. Error pages (/errors)

Because /healthz is processed, you can check the status described later even during warmup. Because static resources are returned, the error page is displayed correctly.

Check the Warmup Status¶

You can check the warmup status with the warmup entry included in the response of the "Health Check Function". To include this entry in the response, you need to enable the "detailed response". For details of the health check function and how to enable the detailed response, refer to "Health Check Function".

You can understand the warmup status from the combination of status and description in the warmup entry.

The HTTP status code of /healthz as a whole is as follows according to the warmup status.

Until warmup is completed (Healthy), /healthz returns 503 Service Unavailable. Therefore, simply pointing the monitoring of load balancers and container platforms to this endpoint prevents traffic from being routed to instances whose warmup has not completed.

Operation with Load Balancers and Container Environments¶

In an environment that operates multiple instances, you can prevent users from ever seeing the error page during warmup by configuring the environment not to route traffic to instances in warmup.

On each platform, specify /healthz as the monitoring target, and configure the platform to add instances to the service after warmup is completed. For details of the settings of each platform, refer to its official documentation.

Supported Versions¶