Problem
wordpress.bench can run PHP workloads, internal REST dispatch, serial host HTTP commands, and outbound HTTP guardrail observations, but it cannot benchmark bounded concurrent external clients against one WordPress runtime.
Using bench process concurrency is not equivalent: it creates isolated runtimes rather than concurrent requests contending on one site's WordPress and database state. Internal REST dispatch is also not equivalent because it bypasses the external HTTP server boundary.
This blocks production-shaped database comparison workloads that need to measure and verify WordPress under concurrent request load.
Proposed contract
Add a generic configured benchmark step such as external-http-load that:
- Targets relative URLs on the active runtime preview origin by default.
- Executes requests from the host side through the HTTP server boundary.
- Accepts bounded
requestCount and concurrency values with conservative hard maximums.
- Supports method, headers, optional body, and one or more expected statuses.
- Uses one runtime for the complete concurrent request set.
- Returns request count, success/failure counts, status distribution, and latency samples/summary in the benchmark scenario.
- Fails the scenario when status or completion assertions are not met.
- Records enough provenance to distinguish host-side external HTTP from internal REST dispatch.
- Keeps public-network access unnecessary; relative runtime URLs are sufficient for deterministic tests.
The step should compose with existing configured benchmark workloads and wordpress.bench result/artifact contracts.
Acceptance criteria
- A deterministic test server proves the configured concurrency bound is exercised and never exceeded.
- A WordPress benchmark integration test sends concurrent host-side requests to one runtime and produces a valid
wp-codebox/bench-results/v1 scenario.
- Invalid/unbounded request or concurrency values fail validation before execution.
- Unexpected statuses and partial request completion fail closed with structured diagnostics.
- Existing PHP, REST, DB inventory, profiler, and external HTTP guardrail benchmark steps remain unchanged.
Downstream consumer: Automattic/markdown-database-integration#345 will use this for a correctness-first native-vs-SQLite concurrent request workload.
AI assistance disclosure
OpenAI GPT-5.6 Sol via OpenCode was used to inspect the current benchmark command contracts, identify the missing single-runtime external concurrency primitive, and draft this issue. The implementation direction and acceptance criteria were reviewed by the operator.
Problem
wordpress.benchcan run PHP workloads, internal REST dispatch, serial host HTTP commands, and outbound HTTP guardrail observations, but it cannot benchmark bounded concurrent external clients against one WordPress runtime.Using bench process concurrency is not equivalent: it creates isolated runtimes rather than concurrent requests contending on one site's WordPress and database state. Internal REST dispatch is also not equivalent because it bypasses the external HTTP server boundary.
This blocks production-shaped database comparison workloads that need to measure and verify WordPress under concurrent request load.
Proposed contract
Add a generic configured benchmark step such as
external-http-loadthat:requestCountandconcurrencyvalues with conservative hard maximums.The step should compose with existing configured benchmark workloads and
wordpress.benchresult/artifact contracts.Acceptance criteria
wp-codebox/bench-results/v1scenario.Downstream consumer: Automattic/markdown-database-integration#345 will use this for a correctness-first native-vs-SQLite concurrent request workload.
AI assistance disclosure
OpenAI GPT-5.6 Sol via OpenCode was used to inspect the current benchmark command contracts, identify the missing single-runtime external concurrency primitive, and draft this issue. The implementation direction and acceptance criteria were reviewed by the operator.