Latency spikes in pfSense under high concurrent TCP connection rates

When pfSense handles a large number of simultaneous inbound TCP connections, administrators sometimes notice intermittent increases in request latency that are not present under low‑load conditions.

The goal is to isolate whether the observed latency originates from contention in the packet filter’s state‑table hash buckets or from the sequential evaluation of QoS traffic‑shaper rules that match many concurrent flows. Relevant constraints include the pfSense version (2.6.x versus 2.7.x), the configured maximum state table size, and the number and complexity of shaper rules. Because the lock granularity was adjusted in later releases and rule‑match cost can vary with rule ordering, it remains unclear which factor dominates under bursty versus steady‑state traffic patterns.

• Does state‑table hash bucket contention become the primary latency driver once concurrent connections exceed a certain threshold, independent of QoS rule count?
• When QoS shaper rules are numerous and match most flows, does rule‑evaluation latency outweigh state‑table lock wait times, especially in pfSense 2.6.x?