Skip to content

bench: measure ClickHouse and MetricsQL o11y paths - #560

Closed
zzylol wants to merge 17 commits into
review/pr553from
bench/o11y-multilang-benefit
Closed

zzylol wants to merge 17 commits into
review/pr553from
bench/o11y-multilang-benefit

Conversation

@zzylol

@zzylol zzylol commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

Why

The ClickHouse SQL and VictoriaMetrics MetricsQL paths need an auditable experiment that keeps all 27 observability queries and every fallback in the denominator. The experiment must reject a benefit claim when a language frontend, published plan, or cross-engine semantic comparison fails.

What

This PR adds a deterministic fixture generator, physical-plan generator, production frontend/compiler auditors, one-command fresh-service runner, structured result comparator, per-query terminal-stage report, and checked-in evidence for one fresh trial with three repetitions.

How

reproduce.py starts from an empty output directory. It generates the OpenMetrics fixture, Prometheus config and TSDB, and physical plan; records their hashes; builds the data-plane binary from that same clean HEAD; runs the production SQL/MetricsQL frontend and compiler paths; starts fresh Prometheus, VictoriaMetrics, ClickHouse, and data-plane state; randomizes query order with a recorded seed; alternates engine order; and records phase-specific mixed-phase CPU ticks, RSS/HWM, storage, ingest time, lifecycle time, raw responses, and structured comparisons.

Before this PR

There was no self-contained way to reproduce the 27-query multi-language measurement. Earlier evidence depended on undeclared /tmp state, recorded a stale backend identity, did not structure all protocol comparisons, and overstated the scope of the observed trials.

After this PR

One command regenerates the checked evidence without a pre-existing TSDB or fixture. The observed result is deliberately narrow and does not establish acceleration benefit:

  • One fresh trial, three repetitions, 27 queries: 81/81 responses from each engine.
  • ASAP MetricsQL: 81/81 exact_fallback; median/p95 5.03/6.34 ms. Native VM: 2.36/9.12 ms.
  • ASAP ClickHouse: 81/81 exact_fallback; median/p95 56.25/179.34 ms. Native ClickHouse: 49.92/169.56 ms.
  • ClickHouse versus ASAP ClickHouse: 81/81 structured matches.
  • VictoriaMetrics versus ASAP MetricsQL: 81/81 structured matches.
  • Prometheus versus VictoriaMetrics: 48/81 strict matches and 33/81 mismatches.
  • Prometheus versus ClickHouse SQL label/value oracle: 81/81 matches. The corpus now records oracle_valid for 27/27 mappings.
  • MetricsQL parser 12/27, early planner 7/27, production compiler/publication 2/27. SQL acceleration frontend 0/27.

Evidence

tools/o11y-multilang/repro-fresh/manifest.json records clean source HEAD 806945b3, the binary SHA-256, immutable image digests, generated fixture and plan hashes, lifecycle/ingest/query duration, and start/post-ingest/post-query resource snapshots. Raw and structured per-request evidence is checked in alongside it.

Verification

  • Python syntax: python3 -m py_compile tools/o11y-multilang/*.py — passed.
  • Rust formatting: rustfmt --edition 2021 --check over all three benchmark examples — passed.
  • Rust examples: cargo check -p control_plane --examples with the shared target directory — passed.
  • Reproduction: reproduce.py --trials 1 --repetitions 3 --seed 20260910 from an empty output directory — passed.
  • Structured comparison: 291 matches, 33 Prometheus/VM mismatches, zero comparison errors across the four comparison pairs.
  • Repository checks: git diff --check passed; generated state directories, logs, TSDB blocks, credentials, and private tokens are absent from the diff.

Architectural decisions

The benchmark uses the production language frontends and compiler APIs and leaves PromQL/SDS contracts unchanged. Exact fallback is a terminal measured outcome. Cross-protocol Prometheus/ClickHouse comparison treats labels and values as semantic fields and reports timestamps and result type as non-comparable; native/proxy pairs compare labels, values, timestamps, result type, and warnings.

Limitations and follow-up

This is one fresh trial, so it does not estimate between-trial variance. CPU is process scheduler ticks rather than normalized CPU time, and process totals cover mixed alternating modes, and container writable-layer size is an operational storage proxy. The generated physical plan contains no corpus sidecars: even q03 and q16 pass offline publication validation; their catalog miss is inferred from the sidecar-free measured artifact, while exact fallback is observed on HTTP. Binder, validator, executor, and warm performance are not exercised by the 27-query run. Native histogram exponential interpolation is outside the classic _bucket q21 query.

Human review — do not complete with an agent

  • The MVP boundary is correct.
  • New conceptual layers or public interfaces are necessary.
  • The before/after description matches the intended product behavior.
  • Human reviewer:
  • Decision and rationale:

@zzylol

zzylol commented Sep 10, 2026

Copy link
Copy Markdown
Contributor Author

Closing because this benchmark is based on the obsolete #559 architecture and its checked-in run measured 27/27 exact fallback before the unified ClickHouse path reached main. A fresh mixed differential and 27-query execution matrix must be generated from current main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant