Use the Client Throttling policy to limit calls to the API for a given client over a window of time by throttling or rejecting requests from that client. Applying this API policy can help protect a Snaplex from being overloaded by too many requests. As requests from a client are received, the count and rate are recorded by the Client Throttling policy. These values are then compared against the limits defined in the Service Tiers section of the policy settings. When the limit is met, the client's ability to make requests is throttled for some amount of time—queueing the request for a short period of time, or rejecting the request 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.
Policy Execution Order
This Policy is executed after the request has been authenticated and authorized.
Expression Enabled Fields in API Policies
|Parameter Name||Description||Default Value||Example|
|Label||Required. The name for the API policy.||Client Throttling||ClientThrottling_WNA|
|When this policy should be applied|
An expression enabled field that determines the condition to be fulfilled for the API policy to execute.
|N/A||request.method == “POST”|
|Service Tiers||Enter levels of a service tier to apply to clients as a condition. Enter each Condition as an expression that is evaluated against a request and used with the specified limits to restrict the request rate. If no matches are found, the limits defined in Default Tier are used.||N/A|
Choose the expression that defines 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.
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 unit of time for the period.
|Throttling||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.||N/A||N/A|
The number of attempts to try before rejecting a request.
|Delay in ms|
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.
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 Tier||Select which Condition to make the default tier. You can set the Per and Limit fields as required.||N/A|
Condition. request.method == 'POST'
Peek Calculation Chart
With the Client Throttling policy enabled, the maximum number of calls that the the system limits within a minute is 1000.
The following expression gives you the smallest number between a 1000 and the ceiling of your limit divided by 10, where the function returns the smallest integer value equal or greater than value:
Math.min(1000, Math.ceil(limit / 10)) = Smaller of one of the two numbers: 1,000 or the ceiling of your Service Tier's Limit / 10
Use the following matrix to determine the peak limit based on the policy Tier Limit:
|Per (Unit of Time)||Less than or equal to 60||Greater than 60|
|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|