For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Open sourceSupportFAQsDocs Home
  • Introduction
    • Overview
    • Retired adapters
      • Overview
        • Overview
        • Base properties
        • Authentication properties
        • SSL/TLS properties
        • Request properties
        • Healthcheck properties
        • Proxy properties
        • Throttle properties
        • Mongo properties
        • Deprecated properties
      • SSL/TLS
      • Throttling
      • Headers
      • Add dynamic headers
      • Add query parameters
      • Update adapter configuration
LogoLogo
Open sourceSupportFAQsDocs Home
On this page
  • Properties
  • Example
ConfigureService instance configuration

Throttle properties

Was this page helpful?
Previous

Mongo properties

Next
Built with

All throttle properties are defined within the throttle object in theItential Platform service instance configuration for the adapter.

Throttling is not commonly needed, but it is useful when an external system cannot handle high load or has concurrent license limitations. When throttling is enabled, the adapter queues requests and sends them to the external system at the rate defined by these properties.

Only enable throttling when traffic has peaks and valleys. Valleys allow the adapter to drain the queue back to zero. If the queue never has time to drain, incoming requests will eventually be rejected because the queue is full.

Properties

PropertyTypeRequiredDescription
throttle_enabledbooleanYesEnables throttling for the adapter.
number_pronghornsintegerYes (if enabled)Number ofItential Platform instances over which the throttle queue operates. Setting this to a value greater than 1 is currently non-functional; a fix is in progress.
sync_asyncstringNo → syncReserved for future use; not currently active.
max_in_queueintegerYesMaximum number of requests to hold in the queue. Requests received when the queue is full are rejected immediately.
concurrent_maxintegerYesMaximum number of requests that can be outstanding with the external system at any one time. The adapter tries to keep this many requests active while draining the queue.
expire_timeoutintegerYesTime in milliseconds to wait after sending a request before sending the next one. This gives the external system time to free up a request slot or license.
avg_runtimeintegerYesExpected response time from the external system, in milliseconds. Used as an initial seed for calculating queue wait times. The adapter replaces this with the rolling average of the last 25 actual requests as they complete.
prioritiesarrayNoPriority rules for ordering requests in the queue. Each rule has a value (integer identifying the rule, matched against the priority field in the request object) and a percent (integer defining queue position as a percentage). A percent of 0 places the request first; 25 places it 25% of the way through the current queue.

Example

This example allows five concurrent requests, queues up to 500 requests, and defines three priority tiers.

1"throttle": {
2  "throttle_enabled": true,
3  "number_pronghorns": 1,
4  "sync_async": "sync",
5  "max_in_queue": 500,
6  "concurrent_max": 5,
7  "expire_timeout": 0,
8  "avg_runtime": 400,
9  "priorities": [
10    {
11      "value": 1,
12      "percent": 0
13    },
14    {
15      "value": 2,
16      "percent": 10
17    },
18    {
19      "value": 3,
20      "percent": 50
21    }
22  ]
23}

In this configuration:

  • Priority 1 requests go to the front of the queue (0%).
  • Priority 2 requests are placed 10% of the way through the queue.
  • Priority 3 requests are placed at the midpoint (50%).
  • Requests with no priority value go to the end of the queue.