> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.itential.com/itential-platform/2023-2/studio/workflows/optimize-workflow-engine-performance/tune-rate-limits/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.itential.com/_mcp/server.

# Tune rate limits

> How to iteratively adjust rate limits to optimize Itential Platform performance.

This topic explains how to iteratively adjust rate limits to optimize performance.

For initial configuration, see [Configure rate limiting](/itential-platform/studio/optimize-workflow-engine-performance/configure-rate-limiting).

## Iterative tuning process

Start with conservative rate limit values based on your system capacity.

Monitor system resources under typical load: CPU utilization, memory usage, and disk I/O.

Gradually increase the rate limit if resources allow.

Test with realistic workflow volumes.

Adjust based on observed patterns.

## Signs to increase rate limit

* Tasks consistently queuing during normal operation
* Queue depth steadily increasing
* System resources underutilized (less than 70% CPU)
* Task workers have idle capacity

## Signs to decrease rate limit

* Sustained high CPU utilization (greater than 80%)
* Memory pressure or out-of-memory errors
* Frequent task failures
* Downstream services reporting overload
* System becoming unresponsive

## Adjust number of task workers

Platform 6.5.1+

In addition to tuning the rate limit, you can adjust `task_worker_thread_count` to improve concurrency. Consider increasing the number of task workers when:

* CPU is underutilized with a single worker
* Task queue depth is high but CPU capacity is available
* You want better concurrency for task processing

The task worker uses every thread you allocate to it. Increasing `task_worker_thread_count` too far can consume all available CPU and memory resources and degrade overall system performance, including API responsiveness and health check reliability.

Increase the value one thread at a time, monitoring CPU and memory utilization after each change before making further adjustments:

| CPU or memory utilization | Status                                             |
| :------------------------ | :------------------------------------------------- |
| Below 80% sustained       | Healthy                                            |
| 80% sustained             | Caution, monitor closely before increasing further |
| 90–95%                    | Reduce `task_worker_thread_count` immediately      |

These thresholds apply to the Platform host, but also monitor MongoDB and Redis memory utilization. Increased task worker activity drives more read/write operations against both services, and memory pressure on either can compound performance issues on the Platform.

## When optimal configuration is achieved

* Workflows complete in acceptable timeframes
* System resources well-utilized (60–80% CPU)
* Queue depths stable or decreasing
* Minimal rate limiting impact during normal operation
* System responsive during peak loads

## When to adjust specific parameters

### Increase task rate limit

* Resources underutilized and workflows slow
* Queue depths consistently high
* Business requirements not being met

### Decrease task rate limit

* System showing signs of overload
* High resource utilization
* Downstream services struggling

### Adjust rate limit period

Adjust the period only if you need to rate limit to slower than one task per second:

* `task_worker_rate_limit=1` with `task_worker_rate_limit_period=2` = one task per two seconds
* `task_worker_rate_limit=1` with `task_worker_rate_limit_period=10` = one task per 10 seconds

For rates of one task per second or faster, keep the default period of one second.

> How to iteratively adjust rate limits to optimize Itential Platform performance.