Adjusting Policies and Thresholds

(This feature can be tried with the Pleasanter Extensions Trial.)

Overview¶

This page explains the role of each rate limit policy and the way of thinking about adjusting the thresholds (limits). For the overview of the whole function, the operation modes, and the behavior when the limit is exceeded, see "Rate Limit Function". For how to write each setting item, see the parameter manual RateLimit.json.

Prerequisites¶

1. This feature is available only to subscribers of the following plans of the Annual Support Service.

Description of Each Policy¶

Each policy is applied to requests of the corresponding function category. The default values are set so that the limit is unlikely to be triggered by mistake in general use, but adjust them according to your environment.

GlobalLimiter (Upper-Level Policy Common to All Routes)¶

Unit: Auto (logged-in user, or IP if not authenticated)
Algorithm and default: TokenBucket (capacity 100 / +50 per second)
An upper-level line of defense applied uniformly to all requests. It is also applied to routes for which no individual policy is set, and ultimately suppresses extreme concentration by a specific user or IP. Paths specified in "ExcludePaths" are excluded from GlobalLimiter.

General (General Screen Operations)¶

Unit: User
Algorithm and default: TokenBucket (capacity 10 / +5 per second)
Applied to general screen operations, such as the record edit screen, various dialogs, and the display of dashboard parts.

Points for adjustment:
If many parts are placed on a dashboard, many requests occur in a short time each time the screen is displayed or reloaded. In environments that use dashboards with many parts, leave room in the capacity (TokenLimit).

List (Lists, Search, and Aggregation)¶

Unit: User
Algorithm and default: SlidingWindow (30 times in the last 60 seconds)
Applied to list display, search, grid operations, cross tabulation, and so on.

Points for adjustment:
For work with many input suggestions for search conditions or many consecutive list operations, leave room in the limit.

Admin (Administrative Operations)¶

Unit: User
Algorithm and default: FixedWindow (30 times every 60 seconds)
Applied to administrative operations such as user management, department management, group management, and system logs.

Heavy (Heavy Processing on the Screen Side)¶

Unit: User
Algorithm and default: Concurrency (1 concurrent)
Applied to processing with a high server load, such as export, import, bulk update and bulk delete, and site package operations. It limits the "number of concurrent executions" rather than the number of times.

Points for adjustment:
With the default (1 concurrent), when one user tries to run a second heavy process at the same time, it waits or is rejected. To allow parallel operations in multiple tabs and so on, raise the number of concurrent executions (PermitLimit).

ApiHeavy (Heavy Processing via API)¶

Unit: ApiKey
Algorithm and default: Concurrency (1 concurrent)
Applied to export, import, bulk processing, and so on via API. It limits the number of concurrent executions per API key.

Api (REST API in General)¶

Unit: Auto
Algorithm and default: TokenBucket (capacity 30 / +10 per second)
Applied to the REST API in general.

Points for adjustment:
For usage that calls the API frequently, such as integration with external systems and batch processing, leave room in the limit. You can also exclude accounts for integration and monitoring with "Exclusions" of RateLimit.json.

AnonymousIp (Unauthenticated Access)¶

Unit: Ip
Algorithm and default: FixedWindow (60 times in 60 seconds)
Applied to unauthenticated access, such as login attempts. It limits per source IP.

Points for adjustment:
In environments where many users share the same IP address, such as an in-house NAT, the limit is easily reached by simultaneous logins at the start of work and so on. Adjust it to a value that does not limit legitimate users. Note that this policy is a limit per IP. As a measure against unauthorized logins (brute-force attacks) on accounts, we recommend using account lockout ("LockoutCount" of Security.json) as well.

PublicForm (Submission of Public Forms)¶

Unit: Ip
Algorithm and default: TokenBucket (capacity 5 / +2 per second)
Applied to the submission of public forms. It limits per source IP.

Points for adjustment:
In shared IP environments such as an in-house NAT, consider expanding the thresholds according to the scale of sharing (for a guide, see "Adjusting PublicForm" in the parameter manual RateLimit.json).

How to Think About Threshold Adjustment¶

1. Observe with "LogOnly" First¶

Observe production-level access with Mode: "LogOnly", and check where requests are limited by mistake from the occurrence of virtual rejections recorded in the structured log (ratelimitlogs.json). By also using the count aggregation by policy ("RateLimitMetricsSnapshot") recorded in the same log at regular intervals (60 seconds by default), you can grasp numerically which policies are triggered and how often. Setting a threshold of at least twice the measured value at business peak times makes it easier to avoid false detections. To send the counts to an external monitoring platform, see Rate Limit Function: Setting the Output Destination of Rejection Logs and Metrics.

2. Decide Per-User (User) Policies by "the Maximum Use per Person"¶

General / List / Admin / Heavy are independent limits for each user. You do not need to increase them in proportion to the number of users (the number of people in the contract plan). Pay particular attention to General when using dashboards with many parts.

3. Consider "Simultaneous Concentration on a Shared IP" for Per-IP (Ip) Policies¶

AnonymousIp / PublicForm are per source IP. If many users share the same IP, such as through an in-house NAT, raise them taking that scale into account.

4. Put Accounts You Want to Exclude in "Exclusions"¶

For users you do not want to limit, such as accounts for batch processing and monitoring tools, register their login IDs in "LoginIds" of "Exclusions" in RateLimit.json.

5. Notes on Running Behind a Reverse Proxy / Load Balancer¶

For per-IP limits to work correctly, be sure to configure the trusted proxies with "ForwardedHeaders" of Security.json so that the source IP address can be obtained correctly. Without this setting, all access is regarded as coming from the same IP, and per-IP limits may not work as intended.

Supported Versions¶

Related Information¶

• Rate Limit Function: Setting the Output Destination of Rejection Logs and Metrics