systemd RateLimitInterval Interaction with Apache2 Event MPM Burst Queueing

Answer

In the configuration you described, systemd’s RateLimitInterval and RateLimitBurst settings do not contribute measurable latency to Apache’s connection handling. Systemd only throttles how often it can restart or signal a unit; it does not monitor per‑connection accept events, so a burst of client connections cannot trigger the rate‑limit logic.

Why the latency spikes are not systemd‑related

• The Apache master process receives no signal for each new client; only the worker threads are created by the event MPM’s accept thread.
• Because systemd sends SIGTERM or SIGUSR1 only when a restart or reload is requested, a sudden influx of connections cannot cause systemd to drop or delay those signals.
• Any latency observed during micro‑bursts is most likely due to the kernel’s accept queue or Apache’s internal request queue reaching capacity, not to systemd rate limiting.

Confirming the absence of systemd interference

1. Check journal logs for rate‑limit events:

   journalctl -u apache2 -b | grep RateLimit
   

   If nothing appears, systemd did not trigger any rate‑limit actions during the burst.

2. Verify the master process does not receive unexpected signals:

   strace -p $(pidof apache2) -e trace=signal -o /tmp/strace.log
   

   Look for SIGTERM or SIGUSR1 entries during the burst window.

3. Correlate client arrival times with Apache access‑log latency:

   tcpdump -i any -n -s 0 -l port 80 -w /tmp/conn.log
   # compare timestamps in /tmp/conn.log with those in /var/log/apache2/access.log
   

4. Optional: repeat the burst test with RateLimitInterval=0 in the unit file and observe whether any change occurs. A difference would indicate a systemd effect, but in practice you should see no change.

Safe use of RateLimitInterval=0

Setting RateLimitInterval=0 disables restart rate limiting for the unit. For Apache this is safe as long as you are comfortable with the possibility of rapid successive restarts if the service fails. It does not affect other services because the setting is unit‑specific.

Metrics to expose systemd rate‑limit events

• Use journalctl -u apache2 -b | grep RateLimit to capture any rate‑limit log lines.
• Filter by timestamp and correlate with Apache’s access‑log latency percentiles to confirm absence of a relationship.

Missing diagnostic detail

Do you see any "RateLimit: exceeded" messages in the apache2 journal during your burst test? If so, that would be the only evidence of systemd actively limiting Apache restarts.