Latency spikes during concurrent notebook launches in default server configuration

The Jupyter Notebook server handles HTTP and WebSocket traffic through a single Tornado I/O loop, and latency can surface only when multiple clients request notebooks or kernels concurrently rather than during isolated sessions. The default deployment runs a single worker process, and each kernel launch spawns a separate Python process whose overhead is not addressed by built-in warm-start strategies. Although additional workers can be configured manually, the documentation does not define a standard concurrency model, leaving the boundary between I/O-loop contention and kernel-spawn serialization unresolved.

Extensions may register extra WebSocket handlers, but their interaction with the core concurrency model is not formally specified, adding ambiguity to latency attribution under load. Behavior may also differ across Jupyter Notebook versions and host infrastructure.

What diagnostic boundary distinguishes I/O-loop contention from kernel-launch serialization in the default server? Does a current release provide a supported configuration for parallel kernel starts without manual multi-worker setup? How should extension WebSocket handlers be factored into concurrent latency measurements?