Split_io bulk thread topology

Does raising ingress, policy, and I/O worker counts together always help under forward_fast?

Numbers are same-host comparisons on a single reference host and are not service-level objectives. See the performance hub disclaimer.

When this matters

It is tempting to raise all split_io worker counts at once (listeners.threads, dataplane.policy_workers, dataplane.io_workers — see worker counts). This study compares a modest baseline (2 of each) with doubling all three together (4 of each) under forward_fast. To see which setting actually helps, change one count at a time: I/O vs ingress (split_io) and ingress concurrency (sync).

What we varied

Varied: all three worker counts together (2/2/2 baseline vs 4/4/4 doubled)
Held constant: split_io, forward_fast, observability off

Evidence

Achieved QPS — split_io topology (forward_fast)

Download CSV

Topology	Runtime	Achieved QPS	Avg latency (ms)	Sent	Completed	Lost	Workers
thin	split_io	138744.2	14.4	1389252	1389252	0	ingress=2, policy=2, io=2
heavy	split_io	258908.7	7.7	2590870	2590870	0	ingress=4, policy=4, io=4

At a glance

split_io topology (forward_fast): heavy is about 1.9× thin (~259k vs ~139k).

Takeaway

Raising ingress, policy, and I/O together helps on this median — and is still not a substitute for single-axis sizing. Topology-heavy (4/4/4) reaches about 1.9× the thin baseline (2/2/2) under forward_fast (~259k vs ~139k).

What to do: treat the bulk pair as a ceiling check, not a tuning recipe. Size one setting at a time with Dataplane runtime tuning and the single-axis studies; remeasure the bulk pair on your hardware.