Tune rate limits | Itential

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

For initial configuration, see 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.