Skip to content

Sync vs split_io

How does dataplane.runtime: sync compare to split_io under forward_fast and forward_slow?

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

When this matters

Choosing a runtime model changes how ingress and upstream I/O share threads. sync keeps receive and forward on the same workers; split_io separates ingress from async I/O workers. Architecture suggests slow upstreams can stall sync ingress harder than split_io; this study checks that claim under paired load shapes on one lab. See also worker counts and the dataplane runtime tuning guide.

What we varied

Evidence

Achieved QPS — sync vs split_io (forward_fast)

Achieved QPS — sync vs split_io (forward_fast)

Download CSV

Runtime Achieved QPS Avg latency (ms) Sent Completed Lost Workers
sync 76269.9 26.1 765379 765379 0 ingress=2
split_io 138744.2 14.4 1389252 1389252 0 ingress=2, policy=2, io=2

Achieved QPS — sync vs split_io (forward_slow)

Achieved QPS — sync vs split_io (forward_slow)

Download CSV

Runtime Achieved QPS Avg latency (ms) Sent Completed Lost Workers
sync 5.7 2508.7 12188 198 11990 ingress=2
split_io 39080.2 51.1 1174342 1174342 0 ingress=2, policy=2, io=2

At a glance

  • sync vs split_io (forward_fast): split_io is about 1.8× sync (~139k vs ~76k).
  • sync vs split_io (forward_slow): split_io is about 6889.8× sync (~39k vs ~6 QPS).

Takeaway

Against a fast upstream, split_io outperforms sync on this lab. Under forward_fast, split_io reaches about 1.8× the QPS of sync (~139k vs ~76k) with lower average latency and little query loss.

Against a slow upstream, split_io still wins completion by a wide margin. Under forward_slow, sync stays near ~6 QPS and lossy; split_io reaches about ~39k completed QPS with little loss on this median. Prefer split_io when upstream wait owns the path.

What to do: prefer split_io when upstream wait matters; confirm on your hardware with --study sync-vs-split-io.

Member scenarios