Event MPM thread pool limits and keep-alive latency under concurrent load

Apache HTTP Server running the Event MPM exposes a fixed worker thread pool governed by MaxRequestWorkers and ThreadsPerChild. When simultaneous requests exceed that pool, additional connections wait in the operating system backlog, producing latency that is absent at low concurrency. Keep-alive handling adds a second constraint: KeepAliveTimeout holds worker threads and sockets open, so under concurrent clients the effective capacity for new request processing can diminish before the numeric thread ceiling is reached.

The unresolved decision is how to balance these documented limits for a specific workload. Reducing KeepAliveTimeout frees threads sooner but may increase connection churn; raising MaxRequestWorkers expands concurrency but requires matching operating system file-descriptor and thread limits to avoid failures. Because the optimal mix depends on traffic patterns, client behavior, and hardware, Apache does not prescribe a single configuration.

Under the general Event MPM model, where distribution defaults and compiled limits vary by version, what observable metrics distinguish thread-pool queuing from keep-alive hold time? Which configuration boundary should be evaluated first when tail latency appears only under concurrency? How can the interaction between MaxRequestWorkers and KeepAliveTimeout be assessed safely before production changes?