Client Throttling rule

Use the Client Throttling rule to limit calls to a Service or endpoint and help protect a Snaplex from being overloaded by too many requests.

The Client Throttling rule limits the number of requests allowed from an individual client for the specified time period. The limit helps prevent Snaplex overload. The Client Throttling rule rule records the count and rate of requests for individual clients. It compares the values against those specified in configuration. When a client meets a limit, it is throttled for some amount of time. The Snaplex might queue requests for a short period of time, or reject them with a 429 Too Many Requests error. If the request is rejected and the client supports the Retry-After HTTP header, the client can retry the request after the specified number of seconds.
In this rule, Service Tiers define rate limits. Each tier has a condition, request limit, and time period. For example, a condition might specify a specific user, IP address or range, role, or method type. A Default Tier applies to any requests that don't satisfy the conditions specified for the other tiers.

API Management 3.0 uses the user ID or IP address for anonymously authenticated users, to calculate rate limiting. Additionally, you can use the remoteUser function to pass into the pipeline automatically with a pipeline parameter.

You can use the IsUserinRole function to define a service tier condition in the Client Throttling rule. The authentication rules define the role, and the Authorization by Role rule performs a check against the service tiers.

Rule execution order

This rule executes after the request passes authentication and authorization.

Settings

Field Description
When this rule should be applied An expression that defines one or more conditions that must be true for the rule to execute.

Default value: N/A

Example: The expression request.method == "POST" causes the rule to execute only on POST requests.

Service Tiers Enter the request limit and time period for each service tier. The Condition determines whether a request applies to the service tier. For requests that don't match a service tier, APIM uses the limits defined in theDefault Tier.
Condition

Required. Choose the expression that should be true to apply this service tier. The expression has access to the request object, so the condition can match on the method, request headers, URI, and the user name or roles.

Default value: False

Example:
  1. To match POST requests: request.method == 'POST'
  2. To match POST requests from users with the admin role: request.method == ‘POST’ && request.isUserInRole('admin')
Request Limit

Required. The number of requests to allow for the defined period. 

This field determines the client’s quota over the long-term with a separate short-term quota used to prevent bursts of requests from overloading a Snaplex. For example, if a service tier is set to allow 5,000 requests per hour, it would be undesirable for all of those requests to be allowed through in a single minute. The SnapLogic Platform calculates the short-term quota as described in Short-term Peak Calculation.

Default value: 1000

Example: 100

Per Required. . The unit of time for the period: DAY, HOUR, MINUTE, or SECOND

Default value: HOUR

Example: DAY

Default Tier Required. Specify the values for the default service tier.
Request Limit

Required. The number of requests to allow for the defined period.

Default value: 5000

Example: 3500

Per Required. The unit of time for the period: DAY, HOUR, MINUTE, or SECOND for the specified default Request Limit.

Default value: HOUR

Example: DAY

Throttling Required. These settings control how requests that are over the limit are handled. A request can be queued and retried if the limit will be refreshed within a certain time. Otherwise, it will be rejected with a 429 Too Many Requests error.
Attempts Required. The number of attempts to try before rejecting a request.

Default value: 3

Example: 3

Delay in ms Required. The number of milliseconds to delay before retrying a request. This field determines the timeframe before the token refill in which requests can be queued. If the request arrives well before the refill time, it is rejected.
Note: The client connection to the server is kept open during this delay and continues to consume resources. Setting this value too high can result in clients consuming too many resources.

Default value: 500

Example: 1000

Description

Required. A brief description of this rule.

Default value: Repeat requests are being limited to no more than the specified limit

Example: Task client throttles

Short-term limit calculation

With the Client Throttling rule enabled, the maxium requests per minute is 1000. APIM enforces a short-term peak based on a calculation that uses this maximum value of 1000 and the request limit you specify. The calculation takes the smallest number between 1000 and the ceiling of your limit divided by 10, and returns the smallest integer value equal or greater than value: Math.min(1000, Math.ceil(limit / 10)).

Use the following matrix to determine the short-term limit based on the rule Tier Limit:

Table 1. Peak Calculation Matrix
Per (Unit of Time) Up to 60 API calls More than 60 API calls
Minutes 5 per second Math.min(1000, Math.ceil(Limit / 10)) per second
Hour 5 per minute Math.min(1000, Math.ceil(Limit / 10)) per minute
Day 5 per minute Math.min(1000, Math.ceil(Limit / 10)) per minute
Note: Although the Client Throttling rule supports the time unit of seconds, the peak calculation doesn't apply to a setting in seconds since that is the smallest increment of time.