Rate Limit assertion allows you to limit the rate of transactions passing through the Gateway for a given user, client IP address, or another identifier. When this limit is reached, the Gateway can either begin throttling requests or it can attempt to delay the requests until the rate falls below the limit. You can also set a maximum concurrency level to prevent a user from monopolizing Gateway resources.
Use this only if you need to limit the flow of transactions entering the Gateway. If you have a cluster of Gateways, the limits entered in this assertion are divided among the number of “up” nodes in the cluster. A node is considered “up” if it has posted its status within the past 8 seconds (configurable via the rate limit.clusterStatusInterval cluster property). The Apply Rate Limit assertion checks the status of cluster nodes every 43 seconds (configurable via the ratelimit.clusterPollInterval cluster property).
The Gateway automatically adjusts the rates internally should nodes be added or removed from a cluster. There is no need to modify the values in this assertion. If no authenticated user is established in the policy, then the IP address of the requestor is used instead in the Apply Rate Limit assertion.
Configure the assertion as below:
- Maximum requests per second
Specify how many requests per second should be processed by the Gateway or cluster.
If the Gateway cluster comprises more than one node, this setting determines whether the value entered in the Maximum requests per the second field is split among the nodes or applied to each node.
- Select this check box to split the value across all the nodes in the cluster. For example, if the maximum is 100, each node in a 4-node cluster will be limited to 25 requests per second. If a node drops out of the cluster, the 100 limits is redistributed across the remaining three nodes.
- Uncheck the check box to allow the maximum requests value on each node. For example, if the maximum is 100, each node in a 4-node cluster will be allowed 100 requests per second, resulting in an effective maximum of 400 requests per second. If one node drops out of the cluster, the effective maximum drops to 300 requests per second (3 x 100).
- It is not recommended to disable burst traffic on a counter that will be servicing multiple concurrent requests, particularly at high rates. Doing so can lead to unintended throttling or delaying of multiple requests that arrive at exactly the same time.
- Spread limit over
Determines whether to allow a burst of requests to be spread across a window of time or whether to enforce a hard cap.
- Select the check box to allow requests to arrive in arbitrary bursts that exceed the Max requests per second rate over an X-second window. This can avoid the throttling of traffic over prolonged traffic bursts. You may enter a context variable containing the X-second window value. This variable can be either single-value or multivalued with a specific index reference.
- Uncheck the check box to disallow bursts. In this scenario, the Gateway only accepts requests arriving no sooner than 1/limit of a second. For example, if the Max requests per second are 100, at least 1/100 seconds must have elapsed between requests. Requests that arrive sooner are either throttled or shaped (based on the “When limit exceeded” setting). Disallowing burst traffic is recommended only for advanced users.
- When limit exceeded
Specify what should happen if the rate limit is exceeded:
- Throttle: Excess requests causes this assertion to fail
- Shape: The property attempts to delay requests to avoid exceeding the limit. If the API Gateway is unable to spare sufficient resources to hold a request any further, a 503 (Service Unavailable) error may still occur.
- Log Only: The property logs that the rate limit has been exceeded, but the assertion does not fail. Audit message 6950 is logged.
- Blackout for: Select this check box to fail all requests for the next X seconds after the limit is exceeded, even if the rate of requests falls below the limits defined in this assertion.
- Maximum concurrent requests
Indicate whether to enforce concurrency limits for a given named rate limiter (as specified by the Limit each setting).
- Unlimited: Concurrency is not enforced. A named rate limiter can have an unlimited number of active requests simultaneously in the Gateway or cluster. This may result in someone consuming a disproportionately high amount of system resources.
- Limited to: Ensure that no named rate limiter can have more than the specified number of concurrent requests passing through this assertion. Requests that exceed the concurrency limit will cause the assertion to fail, with the audit event 6953. You can enter a context variable that contains the maximum concurrent request value. This variable can be either single-value or multivalued with a specific index reference.
- Cluster-wide: If the Gateway cluster comprises more than one node, this setting determines whether the value entered in the Limited to the field is split among nodes or to be applied to each node. This setting is the default.
- Select this check box to split the value across all the nodes in the cluster. For example, if the maximum is 10, each node in a 5-node cluster will result in a concurrency limit of 2 requests per node.
- Clear this check box to allow the maximum requests value on each node. For example, if the maximum is 10, every node in the cluster will be allowed 10 concurrent requests.
- Limit each
Specify how limiting should occur:
- by the User or client IP address
- by the Authenticated user name
- by the Client IP address
- by the SOAP operation within the request
- by the SOAP namespace within the request
- by the Gateway node
Click on Save to complete the configuration. Hit Try with Demo URL to check how assertion work.