Metrics scrape tax under split_io

What does standard scrape cost versus observability off when the runtime is split_io?

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

When this matters

The metrics scrape tax uses sync. If production already runs split_io (dataplane.runtime: split_io), scrape tax on that model is the more relevant comparison. This study pairs observability off and standard scrape under split_io + forward_fast (2 ingress / 2 policy / 2 I/O workers).

What we varied

Varied: observability posture (metrics_off vs metrics_standard_scrape)
Held fixed: split_io, ingress/policy/io = 2, forward_fast, dnsperf recipe

Evidence

Feature tax — metrics scrape under split_io (forward_fast)

Download CSV

Posture	Runtime	Achieved QPS	Avg latency (ms)	Sent	Completed	Lost	Workers
metrics_off	split_io	146802.2	13.6	1469986	1469986	0	ingress=2, policy=2, io=2
metrics_standard_scrape	split_io	139823.3	14.3	1400096	1400096	0	ingress=2, policy=2, io=2

At a glance

metrics scrape under split_io (forward_fast): metrics_standard_scrape costs about 5% QPS versus metrics_off (~140k vs ~147k).

Takeaway

Under split_io, standard scrape costs a modest QPS tax on this median. Obs-off versus standard scrape is about 5% (~147k vs ~140k). Do not assume the sync scrape-series percentage transfers — remeasure on your runtime.

What to do: when sizing scrape on a split_io deployment, remeasure this pair on your hardware. Still pick minimal vs standard from cardinality need.