Runner max-concurrent vs. default event-loop: latency trade-off under concurrent request constraint

Short answer

Raising max-concurrent reduces per-request wait time only when all three conditions hold: (1) requests are I/O-bound with network latency dominating, (2) the target server accepts parallel connections without throttling, and (3) the value is ≤ logical CPU cores. Beyond the CPU count, V8 isolate startup and context-switch overhead inflate total run duration. TLS session resumption on Windows breaks across worker processes because Schannel caches per-process, so each new worker may pay a full handshake (1–2 RTTs) on its first request. The GraphQL plugin's parallel execution flag only splits a single multi-operation document into concurrent HTTP requests inside the same worker; it cannot bypass the single-event-loop bottleneck for REST collections or multiple GraphQL documents.

Confirmed behavior

• Default Runner (all versions): One Node.js event loop serializes every request. Wait time grows linearly with concurrency because each request awaits the previous one's I/O completion.
• max-concurrent setting: Introduced in Insomnia 2023.3. Spawns additional worker processes, each with its own event loop. CLI-only (--max-concurrent) in 2023.3–2024.1; GUI control added in 2024.2+.
• Worker isolation: Workers share no memory. Global variables, auth tokens, and cookie jars re-initialize per worker (~150 ms spawn/teardown overhead on typical CI runners).
• TLS on Windows: Schannel session cache is per-process. Spawning many workers defeats TLS 1.3 0-RTT resumption; each worker's first connection performs a full handshake.
• GraphQL parallel flag: Splits one document containing multiple operations into parallel HTTP requests within the same worker. No effect on REST collections or multiple separate GraphQL requests.

Likely explanation (mark for review)

The UI latency breakdown reports "connection" time but does not distinguish handshake vs. idle socket reuse. When concurrent requests exceed the single event loop's capacity, keep-alive connections queue inside that loop; TLS reuse occurs only for requests that happen to reuse the exact same socket. This means the first request in each worker on Windows pays the handshake penalty, and subsequent requests in that worker may reuse the socket if the server's keep-alive timeout hasn't expired.

Decision checklist

1. Check Insomnia version (Help → About). If < 2023.3, max-concurrent is unavailable; you are stuck with serialization.
2. Profile your workload: Are requests I/O-bound (network wait ≫ CPU)? If CPU-bound (heavy scripting, large response parsing), extra workers add overhead without benefit.
3. Know the target: Does the API rate-limit or have a small connection pool? Setting max-concurrent above the server's limit converts wait-time growth into 429/ECONNRESET errors.
4. Count logical CPUs: Set max-concurrent ≤ logical cores. Diminishing returns appear sharply beyond that.
5. Windows + short runs: If test runs are short (few requests per worker), TLS handshake overhead per worker may dominate. Consider keeping max-concurrent low or using a Linux runner for benchmarking.

Verification you can run today

# 1. Local echo server
npx http-echo -p 3000

# 2. Run a 50-request collection at different concurrency levels
insomnia run collection.json --env base --max-concurrent=1  --reporter=json > run-1.json
insomnia run collection.json --env base --max-concurrent=4  --reporter=json > run-4.json
insomnia run collection.json --env base --max-concurrent=8  --reporter=json > run-8.json
insomnia run collection.json --env base --max-concurrent=16 --reporter=json > run-16.json

# 3. Plot p95 wait time and total duration from the JSON output
# 4. On Windows, capture TLS handshakes:
#    Wireshark filter: ssl.handshake.type == 1
#    Count ClientHello vs. Session Ticket resumptions per worker count

# 5. GraphQL parallel flag test:
#    Create a document with 5 operations, run with flag on/off,
#    compare per-operation latency in Runner timeline

One missing diagnostic that changes the recommendation

What is the typical request count per worker in your test runs? If each worker handles only 1–3 requests, the ~150 ms spawn overhead and Windows TLS handshake penalty per worker will likely outweigh any wait-time reduction. If each worker handles 20+ requests, the amortized overhead drops and max-concurrent ≈ CPU cores usually wins.