systemd RateLimitInterval Interaction with Apache2 Event MPM Burst Queueing

Background

On Debian 12 running Apache 2.4 with the event MPM, burst traffic patterns trigger latency spikes that correlate with systemd service rate limiting rather than worker pool exhaustion. The RateLimitInterval and RateLimitBurst settings in the Apache systemd unit control how frequently the service manager restarts or signals the daemon, yet their effect on connection acceptance during micro-bursts remains undocumented.

Goal

Determine whether systemd rate limiting contributes measurable latency when the kernel listen queue (net.core.somaxconn) and Apache MaxRequestWorkers are both sized above peak concurrency, but request arrivals exceed the default 10-second RateLimitInterval window.

Constraints

• Apache event MPM with MaxRequestWorkers set to 400 and ThreadLimit 64
• Kernel somaxconn raised to 1024
• No memory or CPU saturation observed via pidstat during test windows
• systemd version 252 (Debian 12 default)

Open Questions

1. Does systemd silently drop or delay SIGTERM/SIGUSR1 signals to the master process when burst arrivals exceed RateLimitBurst within RateLimitInterval?
2. Can RateLimitInterval=0 be safely used to disable rate limiting for the Apache unit without affecting other services?
3. What metrics expose systemd rate-limit events for correlation with Apache access-log latency percentiles?