Skip to content

Global

This configuration determines the size of the thread pool used for processing tasks in the application. This value essentially dictates the maximum number of tasks that can be processed concurrently. The optimal thread pool size is calculated based on the number of available CPU cores and the characteristics of the application workload. The formula used is: Number of Threads = Number of Available Cores * U * (1 + W/C) where:

  • Number of Available Cores is the number of cores on your machine that are available for use by your application.
  • U is the target CPU utilization, here it’s 1.0 (or 100% CPU utilization).
  • W/C is the ratio of wait time to compute time, with a default value of 1.5. This assumes that tasks spend 1.5 times as much

time waiting for I/O as they do computing, leading to a thread pool size that is larger than the number of available cores. This can increase throughput by ensuring that the CPU is fully utilized while some threads are waiting for I/O. The current number of active processing threads can be found in the executor_active_threads{name="TaskExecutor"} metric. However, you should ideally consider tuning this value based on the specific workload characteristics of your application. For example, consider using metrics like scribe_ingest_queue_wait_seconds{entry_type="..."} and scribe_ingest_throttle_wait_seconds{entry_type="..."} for I/O wait time (W), scribe_ingest_task_duration_seconds{entry_type="..."} for compute time (C). Also consider scribe_ingest_task_pressure{entry_type="..."} (~1 = steady-state, >1 = backlog) and scribe_ingest_queue_pressure{entry_type="..."} (0..1, where 1 = saturated) to determine if you need more threads to handle the workload. These metrics provide a theoretical optimal value, but it’s recommended to monitor the application’s performance continuously and adjust this value as necessary. A value that’s too high may lead to excessive context switching and resource contention, while a value that’s too low may underutilize the CPU. Additionally, this concurrency value is also used to determine the maximum size of the database connection pools. The batch pool size is calculated as ‘maxPoolSize = concurrency + 5’ (configurable via database.maxPoolSize, max: concurrency * 1.5). The system and channel pools are calculated automatically based on concurrency, transcribe count, and maxPoolSize. See database section documentation for details on total connection count across all pools.

Priority: SCRIBE_CONCURRENCY > config

PropertyValue
OverrideSCRIBE_CONCURRENCY (optional)

See also: database.max-pool-size, database.system-pool-size, database.channel-pool-size

concurrency = ${?SCRIBE_CONCURRENCY}

Operate only in read-only mode — eg only the channel and monitoring server are enabled

Priority: CLI (-r, —readonly) > -Dreadonly > SCRIBE_READONLY > config

Default: false (when not set via any of the above)

PropertyValue
OverrideSCRIBE_READONLY (optional)
readonly = ${?SCRIBE_READONLY}