Apache HTTP Server and Low-Traffic Clients: Does KeepAliveTimeout Tuning Actually Reduce Resource Costs?

I'm evaluating Apache HTTP Server as the front end for a low-traffic internal workload where requests arrive sporadically — often minutes apart. The goal is to reduce per-request overhead and server resource retention without breaking connection reuse for the few bursts that do occur.

My understanding is that keep-alive connections default to a 60-second KeepAliveTimeout, meaning idle connections sit open holding a worker/socket until the timeout expires, and MaxKeepAliveRequests defaults to unlimited per-connection requests. For a workload where consecutive requests almost never fall within the timeout window, every request effectively pays a new TCP handshake anyway, while idle connections still consume slots in between.

The tension I can't resolve: lowering KeepAliveTimeout should free workers sooner, but too low a value risks dropping connections that a burst of requests would have reused. Capping MaxKeepAliveRequests adds another lever, but it's unclear how it interacts with cost at low volume.

Is there a documented or empirically grounded way to choose a KeepAliveTimeout value for sporadic traffic, and does disabling keep-alive entirely ever make sense here? Which metrics (e.g., mod_status connection states) best confirm whether idle keep-alive connections are actually the resource bottleneck?