Unclear concurrency behavior affecting latency in Nuxt.js

Answer

The lack of documented concurrency limits does not directly cause latency; variability is due to blocking work or shared mutable state across requests.

Likely explanation

Nitro runs on a single Node.js event loop per process; without a documented threshold it does not auto‑scale workers. If middleware or plugins mutate module‑level variables after an await, those variables are shared among concurrent requests on the same loop, leading to race conditions and latency spikes.

Confirmed facts

Nitro scaling depends on the deployment preset and process manager, not an undocumented Nitro threshold. Shared state is confined to the same process; it is not transferred between clustered workers or serverless invocations.

Steps to investigate

1. Determine whether the app runs a single Node process or clustered workers.
2. Run a load test with increasing concurrency on a representative route, recording p95 latency and Node.js event‑loop lag.
3. Audit plugin and server middleware code for module‑level mutable objects or arrays that are modified after await; replace them with request‑scoped state (event.context) or per‑request objects.
4. If spikes persist across processes, examine external dependencies or garbage‑collection pressure.

Missing diagnostic detail that changes the recommendation: Is the deployment running a single Node.js process or multiple clustered workers?