OpenAPI 3.0 validation latency spikes under concurrent request loads

Symptom

An API middleware layer that validates incoming requests and outgoing responses against an OpenAPI 3.0 document exhibits low, predictable latency when requests are processed sequentially. Under concurrent load, average validation latency increases disproportionately with the number of active threads, even though CPU utilization remains well below saturation.

Context

The OpenAPI Specification does not mandate a caching strategy for compiled JSON Schema validators. Implementations differ: some validators compile a shared schema object once and reuse it across threads, while others re‑compile or re‑traverse the schema tree for each request. The default behavior can change between library versions, and the presence of a shared‑cache flag is not standardized.

Goal

Determine whether the observed latency growth stems from per‑request schema compilation, lock contention inside the validator, or an interaction with the runtime’s garbage collector, so that a stable, low‑latency validation configuration can be selected for production traffic.

What measurable indicators distinguish per‑request schema recompilation from thread‑safety contention in a given validator? Which configuration flags or initialization patterns reliably enable a shared, thread‑safe schema cache across common OpenAPI validation libraries? How can a benchmark isolate validation overhead from surrounding middleware without modifying application code?