Limits of concurrent request handling in R's single‑threaded interpreter

Goal

Determine the practical concurrency ceiling for R services such as Plumber or Shiny before latency spikes become unacceptable.

Constraints and uncertainty

Base R runs a single‑threaded interpreter, so simultaneous requests are serialized. On Unix, parallel::mclapply forks child processes, adding fork‑and‑IPC overhead that grows with worker count. Garbage collection performs stop‑the‑world pauses; high allocation rates from concurrent request parsing can lengthen these pauses, especially on memory‑constrained hosts. Windows lacks fork, forcing alternative cluster or external‑worker strategies that introduce startup latency. No standardized concurrency API exists, leaving the choice of fork, cluster, or external workers as an unresolved design decision.

Open questions

1. At what request rate do GC pauses dominate tail latency on an 8‑core Linux server?
2. Does replacing mclapply with a parallel::cluster backend reduce tail latency for Plumber endpoints under the same load?
3. Which memory‑allocation patterns in request handling trigger the longest stop‑the‑world pauses during concurrent bursts?