When ColdFusion’s Thread-Per-Request Model Breaks Under 10k Concurrent Users

ColdFusion (on Tomcat) uses a thread-per-request model: each incoming request is handed a worker thread that’s held for the entire duration of that request. This is simple and fast at normal load, but it has a hard ceiling — ColdFusion’s “Maximum Number of Simultaneous Requests” (default 50 Enterprise / 10 Standard / 5 Developer, stored in neo-runtime.xml as requestLimit). Requests beyond that limit queue; if the queue fills, they're rejected or time out. At 10,000 concurrent users the model doesn't "break" because ColdFusion literally runs 10,000 threads — it breaks because a small number of slow requests (a hung database query, a stalled third-party API call) hold their threads, the pool saturates, the queue backs up, and the whole server stalls even though CPU may be near-idle. The fix is rarely "raise the thread limit" (more threads = more memory and context-switching, often making it worse). It's: get slow work off the request thread (async/queues), tune the thread pool and Tomcat connector to match reality, fix the slow queries and add timeouts, cache aggressively, and scale horizontally behind a load balancer. This guide covers the failure mode and every fix, with verified ColdFusion specifics.
Read More