Performance DSL authoring
Status: described, not built — and it depends on research that has not concluded.
What it would do
Section titled “What it would do”Produce a workload model — the workload.yaml from
the sketch — from evidence rather than from
guesswork.
The inputs already exist:
Production access logs. The real traffic mix, the real arrival rate, the real peak shape, the real think time between requests in a session. This is the input that matters most, because the mix in a hand-written performance script is almost always someone’s estimate — and the estimate is reliably wrong in the same direction, over-weighting the journey the team has been working on.
An OpenAPI contract. The endpoints, their parameters, their response shapes. From api-hub.
The SLOs. Which become the thresholds block, unchanged.
The existing end-to-end suite. Journeys are already described there in domain steps; deriving the performance journeys from the same vocabulary is what question 5 of the sketch is about.
Output: a model file, with each figure annotated by where it came from — mix derived from 14 days of access logs, 2.3M requests; peak arrival rate 47/s observed 2026-11-28 09:12.
Why this is the strongest of the four
Section titled “Why this is the strongest of the four”Because the output is small, structured and checkable against its source.
A workload model is twenty-five lines. Every number in it is either measured from a log — verifiable by re-running the query — or copied from an SLO. There is no step where the tool exercises judgement that a reviewer cannot audit in a minute, which is exactly the condition the MCP overview sets for pointing a model at anything.
Compare with test scaffolding, where the tool has to infer the right level and the right conventions, and where a subtly wrong output looks correct.
It also attacks the failure that why a performance DSL identifies: models are guessed, then never revisited. A derived model can be re-derived every quarter against the current logs, and the diff is the finding — checkout is 6% of traffic now, not 10%; there is a new endpoint taking 4% that no scenario exercises.
That regeneration is worth more than the initial generation.
Where its boundary is
Section titled “Where its boundary is”It does not set the SLO. A threshold is a promise to users. It comes from product and operations, and the tool copies it.
It does not decide the run passed. It writes the model; the runner enforces the thresholds; a human reads the result against the previous release. See performance.
It does not write the mechanics. The step implementations — correlation, authentication, data feeding — are ordinary code, reviewed like any other.
It does not invent traffic that is not in the logs. A spike test simulates a load that has never occurred, by definition; that shape is a human hypothesis about a future event, and the tool can scale a measured shape but not imagine one.
What has to be true first
Section titled “What has to be true first”Two prerequisites, and neither is close.
The DSL has to exist. The research may conclude that a convention is enough, or that nothing should be built. This server generates a model file, and if there is no model file there is nothing to generate.
The logs have to be good enough. Session identifiers to reconstruct journeys, timestamps precise enough for think time, and a sampling rate that does not distort the mix. Many access logs are missing at least one of the three, and a model derived from a distorted sample is a confident wrong answer.
If the research concludes that a convention is sufficient, this server becomes considerably smaller and probably more useful: derive the mix and the arrival rate, print them, and let someone paste them into whatever format the team already uses. That version is worth building regardless of how the language question resolves — and it is the version to build first.