docs: load testing guide for serving workloads

[tylerhartwig]

Motivation

There is currently no doc that walks a customer through load testing Materialize: what sits in the read critical path, what they control (Cloud vs self-managed), how to attribute latency to the component actually producing it, and how to build a harness whose numbers can be trusted. A recent field engagement showed how easily load-test latency gets mis-attributed when the client, proxy, and server aren't measured independently.

Changes

Adds doc/user/content/serve-results/load-testing.md, written as a diagnostic guide — each section describes what to measure and how to interpret it, rather than presuming where the bottleneck is:

• The read critical path — client → balancerd → environmentd (coordinator) → cluster replica, with a Cloud vs self-managed "what you control" table so the page serves both audiences.
• Fast path eligibility — EXPLAIN verification, indexing the exact equality key, pushing unions/joins into indexed views, isolating ad-hoc queries.
• Isolation level — pick deliberately, pin explicitly, record with results.
• Concurrency — Little's law, sweeping to find the knee, the queueing signature (flat throughput + uniformly inflating latency).
• Sizing, split by execution path — fast path workloads size clusters for state (with replica utilization as the diagnostic for whether the cluster is the limiter), standard path workloads scale QPS with cluster compute; plus self-managed-only diagnostics for environmentd and balancerd, including the "throttled containers look idle on CPU graphs" trap.
• Building a trustworthy load generator — CPU limits/platform vCPU caps, single-process client ceilings, ramping, tunnels, shared test data.
• Server-side cross-check — mz_internal.mz_recent_activity_log latency vs client-reported latency during the same window.
• Write-side (CDC) testing — hydration before measurement, freshness lag, transformation-cluster memory headroom, source retention windows.
• A final checklist.

Tips for reviewer

• Placement: serve-results/, alongside connection-pooling and isolation-levels (weight 47). Happy to move it if there's a better home (e.g. a future "operational guidelines" section).
• The guide deliberately avoids claims about where bottlenecks usually live and avoids absolute throughput/ceiling statements — it teaches attribution instead. Performance observations that remain are qualitative and tied to a described measurement.
• Self-managed-only sections are marked with a note shortcode; everything else applies to Cloud as well.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (docs-only)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design. (n/a)
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label. (n/a)
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label. (n/a)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post. (docs-only)

🤖 Generated with Claude Code

[linear-code]

EDU-92