Aerospike scheduler threads and namespace write-queue threshold under mixed concurrent load

Goal: Determine whether latency that appears only under concurrent read and write bursts is controlled primarily by scheduler thread count, namespace write-queue high-water marks, or the interaction between both.

Aerospike routes client operations to scheduler threads and holds excess requests in per-node transaction queues before processing. When queue depth rises, write-queue thresholds can trigger backpressure or stop-writes, converting concurrency into tail latency. Public documentation does not fully specify scheduler priority across namespaces or the exact relationship among client connection pools, scheduler threads, and write-queue limits.

Version assumption: scheduler thread defaults and queue thresholds depend on the Aerospike release and deployment profile.

Questions:

• Should scheduler thread count be increased before adjusting namespace write-queue high-water marks for mixed read-write concurrency?
• Is there a documented ratio between scheduler threads, client connection pool size, and transaction queue depth that prevents concurrency-only latency?
• When write-queue backpressure engages, does reducing client concurrency lower latency more effectively than adding scheduler threads?