Throughput policy

Throughput policy represents a setting and a scope that throughput of webhooks is limited to.

When multiple webhooks share a single Throughput policy, throughput of all webhooks is throttled up to maximum number of concurrent connections defined in the policy. This policy is created on project level similar to Frequency policy.

📘

This policy should be used when 3rd party API imposes some limitations on requests per second or number of concurrent requests.

How to set up a Throughput policy

  1. Create a Throughput policy in the Project settings > Campaigns > General > Throughput policies. There you can set individual parameters of the specific policy such as the 'Concurrency limit' or the limit of concurrent requests.

🚧

Remember that the concurrency limit is just an approximation of the requests per second. The actual limit always depends on the latency of the API on the other side. It is always better to use sub-optimal requests per second to ensure you don't go over the limit, and it is also good practice to be aware of what happens if the limit is reached.

  1. In the settings of an individual webhook, you can:
    1. Create a new Throughput policy by clicking on the Cog.
    2. Select Throughput policies you previously created.

📘

When you delete a Throughput policy, a window pops up, informing you of active campaigns in which it is being used. To delete it, you have to find a new Throughput policy for these active campaigns or stop them.

Technical details

On-event campaigns are generally processed with higher priority compared to the rest of campaigns. However, setting a Throughput policy for webhooks in on-event campaigns may have negative impact on the priority in which these webhooks are processed. This will change the order in which they are processed in order to keep the fairness across all the simultaneously running campaigns that have the same throughput policy.

Change Throughput policy in Running Scenarios

When changing from policy A to policy B in a webhook that is actively running, policy B will be applied only to newly executed webhooks. Already scheduled and running webhooks will use policy A. To ensure changes are applied immediately, the scenario must be restarted.

When changing a concurrency limit in a policy within a running scenario, the change is applied immediately.

🚧

Migration

If the webhook was previously using the old Speed limits, they can be still used there. However, it is not possible to create a new webhook with old Speed limits. All new webhooks must use new Throughput policy to limit their speed.